Re: Capabilities across execve
From: Chris Wright
Date: Tue Mar 15 2005 - 19:10:26 EST
* Alexander Nyberg (alexn@xxxxxxxxx) 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
> 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:
> I can see useful scenarios of having the possiblity of capabilities per
> inode (it appears the xattr way wins somewhat in the previous
It's how it should be done.
> Chris, have you seen any capabilities+xattr patches around?
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/