Is capabilities available now?

[Robert Watson]

On Thu, 12 Feb 2004, Chris Wright wrote:

> * traverser at vip.sina.com (traverser at vip.sina.com) wrote:
> > Hi everyone!
> > 
> > I'm new to freebsd and I am very interested in the security
> > enhancement of freebsd.  I've read some docs about TrustedBSD. I
> > still have some questions:
> 
> >   (1) What is the MAC framework? Is it something like Linux Security
> >       Modules( LSM framwork )?
> 
> Yes, it is similar.

I believe the primary differences right now are:

(1) LSM has more "post-hooks" -- i.e., event notifications.  I.e.,
    notifications that controlled events actually took place, whereas the
    MAC Framework's primary focus are access control checks and object
    life cycle events.

(2) LSM provides more check hooks associated with controlling resource
    allocation.  This is something we should explore further for the MAC
    Framework, since it makes it easier to implement kernel modules
    deriving resource controls from access control elements (such as
    labels), making it easier to plug in new resource control models.

(4) The MAC Framework has a more semantically rich notion of security
    label on objects, providing standard system calls and interfaces for
    managing labels on processes and objects, as well as permitting policy
    modules to base decisions on object labels without first dereferencing
    the object structure.

(5) The MAC Framework has an internal notion of policy composition --
    i.e., the loading of multiple policy modules, making use of a
    well-defined meta-policy.  In this sense, it's a lot more like RSBAC.
    LSM allows "stacking" of policies under some circumstances in the
    style of software wrapping, but doesn't provide infrastructure to
    facilitate this. 

(6) LSM provides more complete coverage of Linux IPC objects -- we have
    pretty large changes in the MAC development branch to cover System V
    IPC, Posix semaphores, etc, but they are not yet merged.  We hope to
    have them merged for 5.3, but there's a fair amount of infrastructure
    cleanup and work to make that happen. 

(7) The MAC Framework includes support for labeling a variety of network
    objects, including in-flight packets; I believe that this support in
    LSM was not merged into the base Linux kernel.

(8) The MAC Framework provides stronger infrastructure for integrating
    extended attribute backed on-disk security labels with MAC policy
    modules, "taking care" of a lot of the details.  LSM modules can store
    security labels in extended attributes, but it's somewhat more
    complex, and also requires modifications to each file system; some of
    this is a property of the Linux EA APIs, which work somewhat
    differently with regard to the storing of arbitrary meta-data.

So the primary difference really lies in the strength of semantics -- it
might be accurate to say LSM is more a "set of hooks" than a framework in
that sense, but it's clear their functionality is pretty similar.  The MAC
Framework has been focussed more on supporting traditional labeled MAC
policies, such as Biba, MLS, compartments, and TE, and so attempts to
provide more of the common infrastructure for those pieces. 

> >   (2) If the anwser for the above question is 'yes', then why do you
> >       use this name for the framework ? --MAC, Mandotary Access Control? This
> >       is just a security module in LSM framework.
> 
> The LSM framework is really closer to a MAC framework, as it's primary
> goal is to support access control models.

We've been talking about renaming the MAC Framework to indicate that it's
a general-purpose access control framework (for example, you can implement
DAC policies quite easily).  However, it's unclear what to rename it to. 
Functionality such as IPsec and key management, disk crypto, etc, all are
arguably "security", and so I've shied away from renaming it to be a
security framework.  And for some reason, AC Framework doesn't do it for
me either :-).

> > (3) I'm especially interested in capabilities. Is capabilities
> function now available in MAC framework? If yes, where and how can I get
> the source code of it? 
> 
> There is/was a trustedbsd-cap branch with the capabilities code in it. 
> I believe the trustedbsd-sebsd (port of selinux) branch also has
> capabilities in it.  AFAIK, it's not in FreeBSD-current yet... 

This is correct.  In the past, we've developed a pretty mature
implementation of a variation of POSIX.1e capabilities from FreeBSD, but
decided not to merge it after a risk evaluation.  The Linux
Sendmail/Capability vulnerability concerned me a great deal, and I was
concerned we wouldn't be able to invest enough time in the analysis and
compatibility issues to ensure we didn't introduce that sort of
vulnerability.  The SEBSD branch contains the necessary adaptations of the
kernel privilege checks to allow policies to instrument privilege
decisions, and with some minor changes, you could pretty easily implement
the POSIX.1e privilege model using a combination of the privilege entry
point and process and file labels. 

We don't currently have a merge schedule for the privilege changes -- they
touch every suser() call in the kernel, and I haven't had time to do a
performance analysis.  We're also not all that satisfied with the API,
since POSIX.1e privileges are not all that fine-grained, and a lot of
functionality falls under the catch-all CAP_SYS_ADMIN (which is arguably
not a POSIX.1e privilege, it's a Linux privilege added to make up for a
lack of granularity in POSIX.1e privileges :-).  I imagine that, after
substantial review and interation, we'll merge something resembling the
current capability changes to the MAC branch in the next month or so, and
then into FreeBSD in May.  Right now, the only module that uses the
privilege entry points is the SEBSD code. 

FWIW, one of the reasons we're dissatisfied with the cap_check() changes
is that they in some cases overlap with a more context-rich set of
privilege APIs we had begun to put into the MAC Framework for operations
such as time setting, kernel module management, etc.  This means you get
context such as vnode references and labels, arguments to the changes,
etc.  However, providing that level of granularity pushes more complexity
onto the module writer, not to mention expanding the size of the MAC
Framework policy API.  Lots of trade-offs... 

When we do bring in some variation on the privilege management code, it
will likely be the case that a substantial portion of the FreeBSD "jail" 
model could be moved into a MAC module.  However, some elements still
can't be expressed: primarily, the poly-instantiation style behavior of
the IP stack (poly-instantiation is a strong word for what jail does, but
it's probably the best word).  The MAC Framework generally presents
arguments to access control checks to policy modules as "read-only" --
i.e., those arguments may be passed to other policy models, and if
modified, ordering of module load would change the aggregate policy.
Sometimes, the arguments are considered "read-only" for locking reasons,
due to the caller holding only a shared lock on the object.  Jail works by
substituting arguments during its checks.  It could be improved support
for virtualization in FreeBSD eliminates this problem entirely (i.e., if
we integrate the virtual network stack code into the base system).

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research



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