|Summary:||policy user administration improvements|
|Product:||[Fedora] Fedora||Reporter:||Sean Middleditch <sean>|
|Component:||policy||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Version:||rawhide||CC:||gczarcinski, nalin, pgraner, sds|
|Target Milestone:||---||Keywords:||FutureFeature, SELinux|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-05-12 17:51:52 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Sean Middleditch 2004-04-10 23:38:30 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Epiphany/1.1.12 Description of problem: I have written a script to improve the perceived user friendliness of the SELinux user administration system. This improvement also makes it possible for policy upgrades to occur without any conflicting files (namely, /etc/security/selinux/src/policy/users). The script utilizes an /etc/roles file, which is similar to /etc/passwd. One record per line, separated by colons, with the first column being the user name, the second being the primary role (default login role), and the third column being a comma separated list of additional roles. The script is capable of handling each primary/extra role in special ways, such as using the ifdef(`user_canbe_sysadm', `sysadm_r system_r') construct found in the policy users file. The script is used to generate a users.local file when the make command is run (the users.local file woudl not be distributed with any RPM). It also ensures that all users listed have a 'user_r' role. The script can easily be modified (it's only a small handful of lines of shell script) if this behaviour is unwanted. (i.e., if the user has a primary role of staff_r, is there any reason to give them an automatic user_r role as well?) The ramifications of this are that a) it's very easy to see which users have real user contexts and which just use user_u, as selinux-enabled users are those in the /etc/roles file. Additionally, adding, removing, or examing the roles available to users becomes much easier and simpler, and can be handled using scripts much more easily that the m4 sources of the policy. Further improvement could be made by providing addrole, delrole, and similar commands which modify /etc/roles similarly to adduser/deluser (which should, imo, modify /etc/roles as appropriate as well) and having these commands automatically rebuild and laod the updated policy. I will attach the script and a patch to the policy Makefile for using users.local. Version-Release number of selected component (if applicable): policy-1.10.2-4
Comment 1 Sean Middleditch 2004-04-10 23:39:12 UTC
Created attachment 99305 [details] create the users.local file This script reads /etc/roles and makes the users.local file. It should be invoked by the policy Makefile.
Comment 2 Sean Middleditch 2004-04-10 23:41:49 UTC
Created attachment 99306 [details] policy Makefile patch to use make-local-users.sh and /etc/roles This patch allows the policy to automatically pick up changes to /etc/roles and rebuild the users.local file (as well as make sure one exists, even if just empty).
Comment 3 Sean Middleditch 2004-04-10 23:45:23 UTC
Oops, forgot a note with the original bug. The primary role bit of /etc/roles doesn't actually do anything, because I haven't figured out how to make it do so yet. The idea is that the primary role is the default role you have upon login. However, I always end up with sysadm_r being the default. (It asks to change this upon login, but it's still annoying I must manually select something different while the default is very insecure.) The default should be the primary role. If I figure out how to do this, I'll modify the script/patch as appropriate.
Comment 4 Nalin Dahyabhai 2004-04-12 18:19:45 UTC
I think this approach calcifies the current scheme of making role memberships contingent on tunables, something about which I have doubts. (I tend to think that overuse of preprocessors makes it difficult to get a good picture of the result, and that the policy sources are already skirting that line.) WRT this script in particular, I notice that it grants system_r to any user who is listed as being able to assume the sysadm_r role, which I suspect could become a source of confusion for people. My current understanding of things is that a user's primary role is the first role listed, so you probably want to change the for loop to start with: for role in $primary $extra 'user_r' ; do to have the primary role set up the way you want. This scheme has to be picked up upstream as a prerequisite to using it in Fedora, else management tools oblivious to this scheme (like seuser) will just barf all over it, and I'd rather not go down that road.
Comment 5 Sean Middleditch 2004-04-12 18:53:16 UTC
I agree that macro-ization is ugly and confusing. The entire use of m4 for the configuration system irritates me to no end. I'm working on a paper (not something I plan to "professionally" publish by any means) regarding how the entire configuration system for SELinux could be redesigned to be something close to sane and understandable. The /etc/roles bit is just one teensy part of those changes I'd like to see. "WRT this script in particular, I notice that it grants system_r to any user who is listed as being able to assume the sysadm_r role, which I suspect could become a source of confusion for people." That was in the example in the users file, so I assuemd it was desired behaviour. It's quite easy to change the script in this case; the original version just copied verbatim the roles to the output file. I added the big loop and such specifically to support the macro-ization of roles. If that's not wanted, I'll happily simplify the script. :) The primary role didn't seem to have any affect based on whether it was the first in the last or not. No matter which I choose, I always end up with the default being sysadm_r (for users with that role), staff_r, and then user_r. Having looked at default_contexts file, I'm thinking this is perhaps a bug in the policy, since it seems that file dictates the default roles based on the context of the login process (being it login, gdm, whatever). At least that's my understanding of the system. I can send this upstream if you guys wish. It seemed to me many of the SELinux folks are monitoring Fedora, and they(upstream) don't seem to have a public bug tracker that I can find.
Comment 6 Sean Middleditch 2004-04-12 19:00:41 UTC
Created attachment 99340 [details] alternate make-users-local.sh script This is another version of the make-users-local.sh script which does not special-handle any roles, and also has a few minor cosmetic cleanups.
Comment 7 Sean Middleditch 2004-04-12 21:41:20 UTC
bug #120675 regarding the default_contexts issue. if there's no way for the policy to define this, or to have two default_contexts files (one for user-edited stuff, one for auto-generated stuff from /etc/roles) then we should probably just remove the "primary role" bit from /etc/roles as its misleading and pointless. or, alternatively, we could leave it in for future-support, which we'll hopefully have if its missing now.
Comment 8 Stephen Smalley 2004-04-13 12:09:51 UTC
If the user has a $HOME/.default_contexts file, then any entries from it take precedence over /etc/security/default_contexts. Note that this does not allow the user to assume arbitrary roles; any entries that the user is not authorized for in the policy will be ignored. system_r is included if direct_sysadm_daemon to support direct restarting of daemons from the admin shell. Should go away if we introduce automatic user identity transitions, so that we can transition root to system_u upon such restarts.
Comment 9 Sean Middleditch 2004-04-13 13:18:44 UTC
Hmm. So there's still no way then to let the admin decide who the default is using a nice, easy, centralized roles file at all? in fact, as an admin, I'd rather not let users decide at all, because $DEITY knows one will be foolish enough to pick his staff_r or sysadm_r role because it's more convenient... (granted, people that incompetent shouldn't have those roles, but it'd still be one extra measure, and those can't hurt...)
Comment 10 Colin Walters 2004-04-15 21:50:51 UTC
RE sysadmin control - We could add an argument to the pam_selinux module which made it ignore .default-contexts files in home directories. This would require an addition to the libselinux API too. But that's really independent of this bug. So if I can boil down your complaint - you don't like having the allowed roles for a user and the default one of those defined in separate places. That's probably a reasonable complaint, but I might make an analogy to /etc/password and /etc/groups here. /etc/password defines the default group for a user. /etc/groups lists all the allowed ones. It's generally much more common to configure the set of groups a user is in than to change their default one.
Comment 11 Sean Middleditch 2004-04-15 22:25:54 UTC
The problem is that it isn't possible to centrally configure the default user role *or* additional roles without manually hacking cryptic m4 files which subsequently get blown away by upgrading policy-sources. Putting the default login role in the $HOME dir removes administrator control and destroys centralization (it's not even as centralized as the /etc/passwd and /etc/group files). It's fully possible for the build script to read the default roles from /etc/roles and write ~/.default-context files. I'd rather have a file like /etc/security/user-defaults or something to do this in, however, so we can guarantee users don't over-write them. If we disable ~/.default-contexts (which should be an option), we still need a way to auto-generate the default contexts based on /etc/roles, and modifying /etc/security/default-contexts probably isn't a good idea as it may be modified by the local admin, and it's *really* not robust to have files that are intended to be both human and machine modified.
Comment 12 Stephen Smalley 2004-04-16 13:41:25 UTC
Historical note: Originally, we had a single /etc/security/default_context file that specified a single default login context per user. This had a number of problems, including the fact that we wanted to distinguish based on the caller context (e.g. login vs. sshd vs. gdm vs. crond), that we had to maintain per-user entries in this file, and that we had to duplicate policy information in this file and in the policy itself. That was then changed to have applications obtain the list of reachable user contexts from the kernel based on the policy, then order that list based on a completely _optional_ /etc/security/default_contexts and $HOME/.default_contexts. No per-user entries required, and even default_contexts itself was optional; omitting it would just yield an unordered list of contexts from the kernel. When we made that change, we noted (on the NSA selinux list) the user-configurability of $HOME/.default_contexts as a possible concern, and suggested that we might want to change this to remain administratively controlled, but no one seemed interested at the time. Recently, in response to comments from Fedora users, the logic has been further changed to only return the intersection of /etc/security/default_contexts and the reachable set returned by the kernel to avoid presenting users with confusing entries such as system_r and xauth/chkpwd helpers. So /etc/security/default_contexts is no longer optional. In response to your suggestion, I have no problem with making the use of $HOME/.default_contexts optional and providing a centralized file for per-user entries. Patch should go to the NSA selinux list for consideration.
Comment 13 Stephen Smalley 2004-04-16 13:56:08 UTC
By the way, I see from your comments (assuming that it was you from the username) on lwn that you think that SELinux should have a SubDomain-like configuration. Please think carefully about the implications, as what SELinux can express via its policy configuration (and enforce via its mechanism) goes far beyond the mere program-based and pathname-based restrictions of systems like SubDomain. It is fine to build specialized languages and tools on top of the SELinux language, but if everyone then only uses that specialized language, then much of the power of SELinux will be lost.
Comment 14 Sean Middleditch 2004-04-16 14:05:41 UTC
Stephen: This bug isn't regarding the other changes I want to make to SELinux, which I've specifically not submitted bugs about because of problems you've mentioned. If/when I find a solution that makes easy, sane, UNIXy administration possible using all the power, flexibility, and safety that SELinux can provide, *then* I'll place bugs regarding them. ;-) [btw, the config sample I posted on LWN has all the power of SELinux now, assuming you write the policy compiler intelligently to create correct file contexts and domain. The current configuration system has waaaay too much semantic overload, and requires admins to do things that just plain out aren't necessary were good tools available.] Regarding submitting a patch for default_contexts, what module has the code for that? libselinux? Or the pam module?
Comment 15 Gene Czarcinski 2004-04-16 14:20:12 UTC
Concerning commment #12 about having a centralize files for per user entries, this should be something that is installation configurable as to whether it is used or not.
Comment 16 Stephen Smalley 2004-04-16 14:26:51 UTC
No, the sample config that you posted to LWN doesn't have all the power of SELinux now, regardless of the policy compiler. Think about: - Controlling information flow throughout the system to support confidentiality and integrity requirements; this goes well beyond a program-based or pathname-based model. - Defining and enforcing a processing pipeline (A -> B -> C -> D) so that each stage is unbypassable and tightly bound to specific code in order to implement functionality such as encryption, sanitization, virus scanning, etc. Search the literature for "assured pipelines", or read our papers and check the references. - Controlling processes based not only on the _program_ but on the entire calling context, e.g. user, role, call chain of the program, so that a given program has different permissions when run by different users/roles or when run by different other programs based on their trustworthiness and function. - Partitioning _users_ into classes based on position, clearance, etc, not just controlling programs. - Controlling more than just file accesses, but all inter-process and process-to-object accesses. libselinux contains the get_ordered_context_list function, which is called by pam_selinux to obtain the list of contexts. So you would likely be changing the libselinux internals to support either mode of operation, have the existing interface retain the current semantics, and add a new interface that includes a flag for either mode of operation, and then patch all users (pam_selinux, crond, gdm?) to use the new interface.
Comment 17 Sean Middleditch 2004-04-16 14:31:11 UTC
Gene: what is the use case for that? it would be over-ride by the $HOME entries if those are enabled. otherwise, it would cause no harm, and would be mandatory to support upgrading of policy and management of an /etc/roles system. Stephen: I have no clue what you're trying to get at. The config file I posted to LWN is a config file with *no* limitation to what you can tell it to do. Anything you can put into the policy now that file format could support if you stop and think about it a little, and not assume the quick *sample* I posted to LWN is a complete representation of everything you can do with the format. Not worth arguing about here, this bug has nothing to do with it. Email me privately if you'd like to discuss it in depth. Regarding changing clients of libselinux, why would we need a new interface? The get_ordered_context_list function returns the list of contexts, yes? That's the only place that needs to know about how the admin setup the system. Keep the implementation details where they belong... :)
Comment 18 Stephen Smalley 2004-04-16 14:34:27 UTC
If you want the caller to be able to select the mode of operation, then you would want to add a new interface with that flag, and leave the existing interface intact for compatibility with old callers. If the mode of operation is to be universally applied to all callers, then that is fine; you can just change the internals.
Comment 19 Gene Czarcinski 2004-04-16 14:46:44 UTC
I looked in tunable.te and did not see anything about enabling/disabling using a users $HOME/.default_contexts and that is were I assume something like that would be. If you provide a capability for centralized per-user definitions, then you may want to disable the individual users $HOME/.default_contexts being used (or you may not want to) ... installation option. Similarly, I do not want to have centralized per-user definitions be a forced issue.
Comment 20 Gene Czarcinski 2004-04-16 14:47:45 UTC
This discussion rightly belongs on the mailing list or off line ... not in bugzilla reports.