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.

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).

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.

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.

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.

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.

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.

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.

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...)

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.

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.

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.

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.  

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?

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.

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.

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...  :)

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.

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.

This discussion rightly belongs on the mailing list or off line ...
not in bugzilla reports.