Capabilities/privileges and bounding sets

[Robert Watson]

I've been playing with possible bounding set semantics for POSIX.1e
capabilities, hoping to replace the current jail() implementation on
FreeBSD with a combination of capabilities, MAC protection, and chroot(),
providing respectively limits on privilege, interaction between processes,
and file namespace management.

I'm not sure who else has played with this idea, I know it was of
interest at the last workshop at SGI a few months ago.  Here are the rules
I've been playing with:

Addition of new flag: CAP_BOUND

  Inheritence rules:
        pI' = pI & ~(pB')
        pP' = (fP` | (fI & pI)) & ~(pB')
        pE' = (fE & pE) & ~(pB')
        pB' = pB | fB

  For the purposes of enforcement:
        pE & ~(pB)

  When cap_set_proc() is called, an attempt to enable any of the bits true
  in the bound results in EPERM. 

  For files with no capabilities set, fB may be assumed to be all 0's,
  meaning that it introduces no new bounding.  If fB is not supported in
  the file system, the same is assumed. 

  With appropriate privilege (CAP_SETPCAP), the contents of pB may be
  modified, otherwise EPERM.  A design choice might also be whether or
  not CAP_SETPCAP would allow the removal of bounding on capabilities:
  probably not, only the increased bounding.

  Open question: when an application calls cap_set_proc() with a
  capability set with B set all zeros, and E,I, and P don't violate the pB
  of the process, should it EPERM, or succeed, but not set the bound? 

The open question has to do with whether or not applications will
typically be aware of CAP_BOUND or not.  It's not mentioned in the draft,
so perhaps it's better to assume that an application might not be.

In any case, thoughts are welcome.  I have not yet implemented this, but
would like to in the interests of substantially cleaning up the somewhat
hackish jail() implementation, which individually marks calls to suser() 
with whether or not they should succeed in jail().  Doing it via
capability bounds would mean policy could be more centrally determined,
rather than spread all over the place.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message