Re: Capabilities across execve

[Chris Wright <chrisw@osdl.org>]

* Alexander Nyberg (alexn@dsv.su.se) wrote:
> tis 2005-03-15 klockan 14:42 -0800 skrev Chris Wright:
> > It was meant to work with capabilities in the filesystem like setuid bits.
> > So the patches that have floated around from myself, Andy Lutomirski
> > and Alex Nyberg are attempts to make something half-way sane out of the
> > mess.  The trouble is then convincing yourself that it's not some way to
> > leak capabilities (esp. since some programs use the interface already,
> > like bind9).
> 
> Anyone who uses the current interfaces should not play with the
> inheritable flag, the text I looked at said it was specifically for
> execve. Thus if the application doesn't modify the inheritable mask
> things will look like it has always done. And it really should not mess
> with inheritable mask if it doesn't intend to, that would be a security
> bug.
> We really should be safe doing this.

That's one of the points.  Latent bugs getting triggered is what makes
the change deserving of being conservative.

> > All I can say is work is underway.  There's 3 different patches that
> > will get you to your goal.  I understand that it's a real pain right now.
> > One of the authors of the withdrawn draft has told me that the notion of
> > capabilities w/out filesystem support was considered effectively useless.
> > So, we're in uncharted territory.  BTW, thanks for reminding me of
> > scripts, I had been testing just C programs.
> 
> I wouldn't call it useless, retaining capabilities across execve +
> pam_cap is a very useful thing, on my machine I can give myself a few
> capabilities that have always annoyed me (iirc the database that wanted
> mlock as regular user would have been solved aswell).

Yes, that's useful, but having 3 sets and complicated rules for
combining task and file based sets is not really necessary for that.

> Regarding fs attributes:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/0171.html
> 
> I can see useful scenarios of having the possiblity of capabilities per
> inode (it appears the xattr way wins somewhat in the previous
> discussion).

It's how it should be done.

> Chris, have you seen any capabilities+xattr patches around?

http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4-fcap/

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net