Is capabilities available now?

[Robert Watson]

On Sun, 15 Feb 2004 traverser at vip.sina.com wrote:

>   The analysis from Robert Watson and Chris Wright are really great!
> Helped me a lot. Thank you very much. 

Sure.  You managed to get an LSM guy and a TrustedBSD MAC guy in the same
room, and I guess the results were pretty productive :-). 

> > 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 :-).
> 
> I think ACF( Access Control Framework ) is pretty good.

Which actually resembles the terminology of the GFAC (Generalized
Framework for Access Control -- Abrams and La Padula), which seems
appropriate, and would also increase parallels with RSBAC.

> > > > (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,
> 
> Is the code still available? Where and how? I really want to see it. 
> 
> http://www.trustedbsd.org/components.html said:  ...but is based on an
> older FreeBSD 5.0-CURRENT snapshot. Elements of this implementation are
> being updated for FreeBSD 5.2 and will be available in 2003Q3 as part of
> the MAC Framework...  What is exactly the current status of TrustedBSD
> capability? 

There are three parts associated with implementing capabilities support:

(1) Adapting the kernel privilege checks to carry information on the type
    of privilege being used, so that you can centralize the access control
    logic.  This usually consists of searching the kernel for suser() and
    suser_cred() calls, analyzing the use, and substituting a call to
    cap_check(cred, privilege_mask).  In some cases, you have to
    restructure the calling code to avoid privilege decision caching where
    the privilege is used to authorize different types privilege (this
    occurs in the IPv6 ioctl code, for example).

(2) Implement kernel capability logic, file system storage, initial
    capabilities for init vs. kernel processes, any compatibility modes
    with setuid/uid 0 privilege, and any policy controls.

(3) Adapt userspace to understand capabilities, including converting
    setuid (and some setgid) applications to understand and manage their
    privileges, perhaps implementing an /etc/capabilities to bind
    capability sets to users, etc.

In our 5.0-CURRENT implementation, we did all three of these.  In our
current implementation on the SEBSD branch, we've done only (1), so that
the ported FLASK/TE policy module can participate in kernel privilege
decisions in a manner similar to the SELinux policy module on Linux.  In
the kernel implementation of kern_cap.c, MAC policy modules can restrict
privileges granted to a process, but not broaden privileges, so as it
stands, a MAC Framework module can only implement a subset of the complete
POSIX.1e spec (replacing superuser privilege).  It would be easy to modify
it so that modules could also grant privilege, but there are some
questions about how best to handle multi-module composition.  One approach
might be to have one entry point to handle "deny", and another to handle
"accept", and run the deny entry point first.

I've put up a copy of the old trustedbsd_cap branch work on fxr.watson.org
if you want to take a look -- it's not directly diffable against a recent
TrustedBSD/FreeBSD tree due to its age, but might be interesting reference
material.  Here's the CAP branch:

  http://fxr.watson.org/fxr/source/?v=TRUSTEDBSD-CAP

And the SEBSD branch:

  http://fxr.watson.org/fxr/source/?v=TRUSTEDBSD-SEBSD

In both, you can take a look at src/sys/sys/capability.h and
src/sys/kern/kern_cap.c.  Also, do an identifier search on cap_check() and
cap_check_cred().  You can take a look at the SEBSD/FLASK/TE code here:

  http://fxr.watson.org/fxr/source/security/sebsd/?v=TRUSTEDBSD-SEBSD

In particular, sebsd.c is the "plug" between the MAC Framework and FLASK.

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