Re: patch to make Linux capabilities into something useful (v 0.3.1)

On Sun, Sep 10, 2006 at 12:36:31PM +0000, Pavel Machek wrote:
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 ;-).

No, this would be an alternate model that if enabled would give us the
full Posix Capabilities draft compliance and which would hopefully
make us be mostly compatible with Trusted Solaris and Trusted Irix.
Like SELinux, it's something that would have to be explicitly enabled,
and yes, does break compatibility with standard root privileges ---
but then again, break apart root privs was the whole *point* of the
Posix capabilities design....

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.

Per system defaults would also be good, but I believe it would also be
a good idea for their to be per-filesystem defaults. Yes, not all
filesystems would support per-filesystem defaults, since this requires
extensions in their superblock; for those, they would only have the
per-system defaults.

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

But that means libc would need to know which bit positions were
positive capabilities, and which were negative, and adding new
capabilities would require a matching change with libc. Not a good
idea, I think....

- Ted
-
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/

Relevant Pages

  • Another 2.6.13-ck3 locks machine after some time, 2.6.12.5 work fine
    ... 0000:00:00.3 Host bridge: VIA Technologies, ... Capabilities: <available only to root> ... I/O ports at b000 ...
    (Linux-Kernel)
  • Re: posix capabilities inheritance
    ... The intent behind the POSIX capabilities system ... privileges it is allowed to inherit. ... I see no security ... because you have the root password, you don't want to run as root all ...
    (Linux-Kernel)
  • Re: [patch] unprivileged mounts update
    ... Serge found a problem with the fsuid approach: ... remove filesystem related capabilities. ... Root should be able to set this flag on any mountpoint, ... If it were really the equivalent then I could keep my capabilities:) ...
    (Linux-Kernel)
  • Re: patch to make Linux capabilities into something useful (v 0.3.1)
    ... that unmarked executables inherit no capabilities, ... security principle of "least privileges". ... used root, cd'ing to a colleagues source tree, su'ing to root, and who ... default inheritance capability for that filesystem should be in the ...
    (Linux-Kernel)
  • Re: What does it all mean?
    ... And I know it is not a good for Mysql to run as root ... It will start your real mysqld ... > for example needs root privileges to bind to port 80, ...
    (Fedora)