Capabilities/privileges and bounding sets

[Andrew Morgan]

Robert Watson wrote:
> Addition of new flag: CAP_BOUND
> 
>   Inheritence rules:
>         pI' = pI & ~(pB')
>         pP' = (fP` | (fI & pI)) & ~(pB')
>         pE' = (fE & pE) & ~(pB')
>         pB' = pB | fB

Your rules do not appear to be based on those of DS17. DS17 has:

       pI' = pI
       pP' = (fP & X) | (fI & pI)
       pE' = (fE & pP)

For bounding sets, I'm using the 'X' in DS17 implemented as:

       X = fB & (~pB)

fB is a per-filesystem-mount bound, ~pB is a per process bound: pB' =
pB. [I'm trying to use your notation for pB - namely the '~' of the
mask. Although elsewhere I'm likely to use another notation.]

The decision about whether to leak (pI & pB) bits through process
execution is entirely up to the program that restricts ~pB and then does
an exec(). Namely, one would expect such a program to force (pI & pB) =
0, but if there is a reason this isn't appropriate in individual cases,
then said program wouldn't be required to do it.

The fI value seems to need a mask associated with it too. I'd probably
prefer to map fI on the disc to (fI & fB) in system. [This is arguably
the only extension beyond DS17.]

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

For Linux, I'm pursuing this restriction on pP':

    (pP' & fP) == fP

Namely, I interpret fP to be the minimum capabities that the program
requires to function correctly, so if any of those capabilities are not
available, then the file cannot be executed.

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

Why is this explicit restriction needed? Can't you rely on the exec()
rules?

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

Linux will probably be closer to SGI here, namely CAP_SETPCAP will
remove the pP bound on raising new capabilities in pI. [We've had some
debate about whether to make CAP_SETPCAP wholely equivalent to eip=~0
(which I understand would make us completely compatible with SGI), but
especially for chroot jail type things this looks insufficiently
restrictive.]

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

I'm not sure what this means.

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

We'll probably extend the 'posix' API to read and write the two flavors
of bound. That is, make them visible. How has not been decided.

Cheers

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