Re: Capabilities across execve

[Alexander Nyberg <alexn@dsv.su.se>]

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

bind9 actually sets inheritable, but I don't see it doing any exec in
the whole package, so it should be safe. I'll look for other large
common packages using capabilities.
I don't think this necessarily is 2.7 material, but otoh if it has
waited this long there doesn't appear to be that kind of rush to get it
in.

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

However I never saw any real clean solution for the problem and I would
call this better and more general for this kind of problems.

> > 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, I'll have a look at this.