Is capabilities available now?

[Chris Wright]

* Robert Watson (rwatson at FreeBSD.org) wrote:
> On Thu, 12 Feb 2004, Chris Wright wrote:
> > >   (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.

Do you ever find this as a limitation in the MAC framework?

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

Will be interesting to see how this evolves as we look at a more
comprehensive resource control framework in Linux (outside the scope of
LSM).

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

This is something I really like in the MAC framework.

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

Heh, let's be honest, stacking in LSM is pretty pathetic ;-)  We were
given a limitation of "no stacking" as generic policy composition leads
to arbitrary results.  However, this is more a headache than a feature I
think.  I appreciate the compostion feature in the MAC framework.

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

Indeed.  There are some facitilties for tagging, esp. outbound, if you
use some of the hooks netfilter provides.  However, the full
infrastructure required for something like CIPSO tagging was rejected.

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

Well put.

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

Heh, names are always hard.  I guess this thread is case in point that
security framework is confusing ;-)

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

Do you plan to support the POSIX.1e filesystem bits for capabilities as
well?

> 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,

I guess I'd be surprised if there was a significant performance overhead.
But that's neither here nor there.  It's great that you are careful with
each change ;-)

> 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

Yes, we consider the capabilities as coarse grained, esp. when compared
with per subject/object labelling.  CAP_SYS_ADMIN is the kitchen sink,
and is a primary offender of not making capabilities fine-grained enough to
be really useful.

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

We've had the same issues.  In fact, some of the LSM hooks were rejected
because they were colacacted with existing capability checks.
Eventually, I'd prefer to move the capability checks into the LSM
framework, but it doesn't look very realistic for all drivers, etc.

> 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

We've got a BSDjail module.  It's a nice example of useful, simple,
relatively configuration free model.

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

Definitely.  We've had to reject work done that needs offer virtualized
objects to caller.  As a consequence, I believe the virtualisation work
will become separate from the security framework.

Thanks for the great analysis!

cheers,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

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