TrustedBSD is a branch of the FreeBSD codebase that serves as its own unique
platform as well as a source for merging Access Control Model specific
changes back into the FreeBSD 5 branch. Within the Linux space, the Linux Security
Modules project aims to accomplish a very similar goal for the Linux kernel: incorporating
fine-grained access rights into the service providing components (i.e. interprocess communication, filesystems, memory management, etc) of their respective platforms. This involves major
changes to kernel subsystems and integration of various new components including
extended file attributes, access control lists, and capabilities.

Xu Hao kicks off a trustedbsd-discuss@ thread inquiring on the status of
capabilities code in TrustedBSD, as well as the differences between LSM and the
MAC Framework. Robert Watson expands on a reply from Chris Wright, summarizing a
set of 8 essential differences with this last paragraph:

“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 focused 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.”

Chris Wright contributes to the discussion with some interesting background on decisions made with LSM:

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

Access control is a fundamental component to security in modern operating systems - it dictates the permissions, privileges, and rights of ‘subjects’ (a requesting entity, typically processes and users) on ‘objects’ (the entity being requested, typically files and devices). In Unix and its derivatives, the access control model is based on the primitives of read, write, and execute bits. In addition, the 'root' user, being the de-facto administrator of the system, has privileged access to all objects without exception. This becomes problematic when vulnerable services and executables are run under root privileges. In this sense, the root user (or the equivalent privilege) has historically been the most coveted and enduring target of malicious use.

While we've seen many preventative workarounds for the issue - some adequate in concept (i.e., non-executable stack protection, jail(), privilege separation, etc.) - open-source *nix platforms are still behind in providing users with a consistent infrastructure for alternative fine-grained access control models. By ‘fine-grained’ we mean both ‘more specific’ and more enumerable. The {read,write,execute/user,group,other} construct will become increasingly insufficient for expressing the more complex requirements of future computing efforts in untrusted and hostile environments. Current ACM work tackles the broader root privilege issues that are normally hacked around by tools such as sudo. In fact, the key policy used within LSM (SELinux) and most MAC Framework policies are designed to ignore the encompassing rights of root - treating that account like any other normal user.

Aside from a difference in design decisions between the two projects, this discussion also revolves around the implementation of capabilities. The concept of capabilities involves the enforcement of ‘least privilege’. Capabilities are a method of constraining privileges such that a subject X can use an object Y, with Y only inheriting the privileges necessary to do the specified work. The intended result is a system where processes, among other examples, have only the most minimal set of rights to complete work within context of the user running them - including root. Work on extended file attributes and access control lists are outside of the scope of this thread, but they have been implemented for quite some time in both FreeBSD and LSM. As Watson points out below, capabilities will be a bit trickier.

From: traverser [email blocked]
To: trustedbsd-discuss [email blocked]
Subject: Is capabilities available now?
Date: 2004-02-12 2:14:56

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

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

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

  Thank you!

  Xu Hao Beijing



From: Chris Wright [email blocked]
Subject: Re: Is capabilities available now?
Date: 2004-02-12 20:06:33

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

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

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

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



From: Robert Watson [email blocked]
Subject: Re: Is capabilities available now?
Date: 2004-02-13 20:08:34

On Thu, 12 Feb 2004, Chris Wright wrote:

> * traverser@vip.sina.com (traverser@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@fledge.watson.org      Senior Research Scientist, McAfee Research



From: Chris Wright [email blocked]
Subject: Re: Is capabilities available now?
Date: 2004-02-13 21:57:13

* Robert Watson (rwatson@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

• Archive of above thread
• Introduction to Linux Capabilities