Capabilities/privileges and bounding sets

[Robert Watson]

On Wed, 20 Sep 2000, Andrew Morgan wrote:

> > inheritance properties.  Right now, in my implementation I am providing a
> > cap_set_proc_mask(cap_t cap) call, which allows the setting of the process
> > mask, as I'm not currently including it in the base three flags for the
> > capability set.  I'm not entirely decided if this is the right means for
> > managing the inherited capability mask as yet; the other possibility we've
> > been thinking about is to add CAP_BOUND, a new flag for each capability,
> > indicating whether that capability is permitted acording the the current
> > bound.
> 
> Are you saying that you have extended your definition for cap_t to be a
> four member set, but that the regular cap_set_{proc,file}() API ignores
> the value of the new fourth member? Only your cap_set_proc_mask()
> function will set its value?

My struct capability (cap_t) doesn't include the new mask, I added it
seperately to the process credential structure.  See below.

> By adding CAP_BOUND (for functions like cap_[gs]et_flag()), you can
> leverage other parts of the API to manipulate this new set?

The argument I'm going to make is still somewhat tentative and I'd greatly
appreciate your thinking on the issue to find the best way to handle this. 
The reason I didn't add CAP_BOUND is that I'm worried about existing
code/utilities that will call cap_init() to return a fresh capability
structure.  Right now, my bounding capability flag set refers positively
to the set of approved privileges.  That is, rather than the "not"
notation based on  ~pB being used in X, using pB directly.  In essence
turning the bound into, ``This is the approved set of privileges'' which
seems more in keeping with the spirit of capabilities, and also more
compatible with the expression of X.  However, this means that if
CAP_BOUND is supported, and legacy code with CAP_SETPCAP attempts to
configure a capability with the rights it requires, not knowing about
CAP_BOUND, it will always produce invalid capability sets -- CAP_BOUND
will be with all flags disabled, overriding the positive flags added by
the code.

There are a few ways to deal with this:

1) Have a CAP_BOUND flag in cap_t, but ignore it in some set of situations
   (cap_set_proc(), cap_set_file() for example)
2) Have the bound be completely independent from storage, setting, and
   getting of cap_t
3) Negate the flags in CAP_BOUND, which also runs you into problems,
   because then cap_init() returns a capability with all bounds disabled,
   requiring the values to be ignored in cap_set_* anyway :-).

(2) seemed safest to me, so there is no CAP_BOUND, and the bounding set is
not part of cap_t.  You could imagine storing CAP_BOUND in there for
programmatic reasons, but not ever allow it to be set, retrieved, or used
by userland processes.  This might simplify the hooking of capabilities to
a process.

> How were you planning to set the bound on a filesystem?

Right now, this is not implemented, but I currently was thinking in terms
of this being a property of either (a) the mounting process, or (b) the
file system itself.  (a) is useful for mounting untrusted media, and would
presumably be an argument to mount() similar to nosuid support, but (b)
is appealing, along with meta-data indicating whether capabilities should
be used at all, and if so, which.


  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