Role and label selection question

[Robert Watson]

Since the MAC implementation is gradually becoming more usable, we're
beginning to start integrating rudimentary MAC support into userland
applications.  This means matching up the kernel credential/security value
and modification primitives to broader userland concepts such as "user"
and "login".  Right now, we have a simple hack to add basic MAC support in
userland, but there are a lot of deeper issues to consider.  This e-mail
is in part to solicit information on how other systems address some of the
same general concerns.

Currently, MAC labels on processes include components for each of the
possible MAC policies in the system.  When the label on a process or
object is modified, all policy components must be updated.  We have plans
to address this by allowing software only understanding specific policies
to work in environments where additional policies are present, but we're
holding off on addressing this until we have more consistent labeling and
enforcement.

Right now, the "quick hack" to get labels associated with users was to
define a complete multi-policy MAC label for each user class, defined in
/etc/login.conf.  For example, the 'default' class currently contains:

...
        :umask=022:\
        :label=biba/low,mls/low,te/default_d:

This maps exactly one MAC label to each user, although if the label is
changed live, there may be processes that persist using the old label. 
Many MAC systems will permit multiple labels (possibly roles) to be
associated with a user, and give the user the option to select among those
roles, possibly also based on execution context.  For example, at least
one DTE prototype prompted the user to select a role domain when they
logged in.  This sort of behavior is desirable, and suggests that either
login classes need to support multiple labels with a selection mechanism,
or another database (/etc/mac, for example) should be used.  I'm leaning
toward another database.  But the basic question here is, is supporting
multiple labels per user something useful?  Should we also attempt to
support a notion of user label ranges?

Follow-on question: in the single-label environment, the lack of user
intervention required to select a label when acting on behalf of a user is
a greatly simplifying concept.  login always knows what it should do, as
do sshd, xdm, etc.  However, additionally, tools such as cron, sendmail,
and at also know what to do.  If a role is requested at login, what
mechanism should be used to do that, and if a scheduled or asynchronous
user event occurs (mail delivery, recurring cron job), how should a label
be selected?  I'm told that SELinux takes the approach of a default label,
to be used in such situations, possibly selectable on a per-context basis.
When it comes to selecting the label in a user-aware context, there are
questions about how that should be done: should they be in a default
label, and then have a tool to modify the label?  This causes problems for
direct login to window systems, where due to application interaction, you
might want your word processer as well as windowing environment to run
under the modified role.  Or you might just want a specific xterm to.

Anyhow, thoughts on this topic would be appreciated.  Until we've come to
some reasonable conclusions on an approach, I'll stick with the single
login.conf label, and use that in all situtions.  Right now, that causes
problems for tools like sendmail and newsyslog, especially without a
notion of polyinstantiation.  Solutions to these problems should attempt
to address how to make these tools work correctly.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message