Messages in this thread | | | Date | Sun, 10 Sep 2006 12:36:31 +0000 | From | Pavel Machek <> | Subject | Re: patch to make Linux capabilities into something useful (v 0.3.1) |
| |
Hi!
> > I emphasize that the filesystem support patch described above, alone, > > will *not* solve the inheritability problem (as my patch does), since > > unmarked executables continue to inherit no caps at all. With my > > patch, they behave as though they had a full inheritable set, > > something which is required if we want to make something useful of > > capabilities on non-caps-aware programs. > > This is what scares me about your proposal. I consider it a *feature* > that unmarked executables inherit no capabilities, since many programs > were written without consideration about whether or not they might be > safe to run without privileges. So the default of not allowing an > executable to inherit capabilities is in line of the the classic > security principle of "least privileges". > > I agree it may be less convenient for a system administrator who is > used root, cd'ing to a colleagues source tree, su'ing to root, and who > then types "make" to compile a program, expecting it to work since > root privileges imply the ability to override filesystem discretionary > access control --- and then to be rudely surprised when this doesn't > work in a capabilities-enabled system. However, I would claim this is > the correct behaviour!
But this is not how it behaves today, right? I do not think you could push 'break-make-as-root' as a bugfix to -stable ;-).
> absence of an explicit capability record. Both of these should be > overrideable by a mount option, but for convenience's sake it would be > convenient to be able to set these values in the superblock.
Would per-system default capability masks be enough? ... .... okay, probably not, because nosuid is per-mount, and this is similar.
> As far as negative capabilities, I feel rather strongly these should > not be separated into separate capability masks. They can use the > same framework, sure, but I think the system will be much safer if > they use a different set of masks. Otherwise, there can be a whole > class of mistakes caused by people and applications getting confused
Can we simply split them at kernel interface layer? Libc could do it, preventing confusion...
> The solution is to _extend_ the capabilities system: for example, by > adding default inheritance masks to cater for system administrators > who value convenience more than security, and to add new bitmasks for > negative privileges/capabilities.
Agreed. Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |