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

[Robert Watson]

On Mon, 8 Jan 2001, Andrew Morgan wrote:

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

I agree that that is potentially confusing.  I guess I'm wondering why a
flavor is necessary -- why not just:

int	cap_set_bound(cap_t cap_p);
cap_t	cap_get_bound(void);

This would assume that a capability bound actually consists of a complete
capability set including the three flags currently defined,
{CAP_PERMITTED, CAP_EFFECTIVE, CAP_INHERITABLE}.

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

Sounds good to me, and has precedent given the "nosuid" mount option
available on many platforms.

An area where I don't feel I've reached many useful confusions has to do
with enabling and disabling of various features, and layering of those
features over extended attributes.  Right now, my file system code stores
EAs, and does mapping of ACLs to EAs.  The capabilities implementation is
entirely above the file system layer, implemented as part of the system
call services (i.e., cap_{get,set}_{fd,file}, exec() changes).  The
problem with this approach is it doesn't allow the file system to reset
the capabilities when the file is modified (and various other relevant
occasions).  Making the file system aware of capabilities would allow
this; at the same time, it would involve exposing the presence of
capabilities at the VFS layer, rather than purely extended attributes. 
Maybe this isn't a problem, but it does complicate VFS and start to lock
you in as to what is getting passed around.  There's also the issue of NFS
and non-{UFS,ext2fs,FFS} file systems. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


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