[Linux-privs-discuss] Re: Capabilities/privileges and bounding sets

[Andrew Morgan]

[Time passes...]

OK, I've a working Linux patch for filesystem capabilities that
implements the independence of euid=0 and capabilities as we discussed
mid last year. A process bouding set and a per-process (tree) turning
off of the euid=0 superuser. I'm thinking about putting it out for folk
to play with, but there is one thing I would like to complete first.

What remains to be done is an interface for getting/setting the process
bounding set (X). Support for the kernel using it is there, but changing
it is not.

Robert Watson wrote:
> 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.

OK, agreed sort of. But that leaves us with the need to establish an
API.

I'm leaning towards creating a pair of functions

   int cap_set_bound(cap_t cap_d, cap_flag_t flavor);
   cap_t cap_get_bound(cap_flag_t flavor);

that will use the 'flavor' component of the supplied 'cap_d' to get/set
the current bonding set. This seems to be a minimal change to the
capability API but one that can leverage all of the stuff that the
current API provides and basically conforms to your point 2 with which
I'm in agreement.

The issue that concerns me (which makes this ugly), is that the text
manipulation behavior of the existing API might lead to confusion.
Namely:

   cap_d = cap_get_bound(CAP_PERMITTED);
   textual = cap_to_text(cap_d, NULL);
   printf("current CAP_BOUND: \"%s\"\n", textual);

Which displays something like this: "=p". I'd really rather have
something like "=x". The hacks I have to do to work around this visual
confusion make me unhappy about the idea since what I liked about this
idea is that its a minimal perturbation to the current implementation.
Do you think I'm being too picky? Want to suggest something else?

> > How were you planning to set the bound on a filesystem?
> 
> Right now, this is not implemented, but I currently was thinking in terms

Me neither... I'm leaving this one out for the moment. (What I have is a
mount option to turn filesystem capabilities on/off which I guess is a
crude sort of mask. ;)

Cheers

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