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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
