>> I don't see the problem. A suid-root binary is immutable for everyone
>> but root. Only root can grant capabilities.
>
> No. Wrong.
No, right. :-)
> It's statements like this that are frustrating to people who want a
> real capabilities-based system. On a capabilities-based system, there
> is no root. UID 0 may not be an administrative account; it may be
> just another user. That's unlikely to happen in the near-term with so
> many assumptions out there about UID 0, but it is an eventual goal of
UID 0 will always be special, even without unlimited capabilities.
Someone needs to own the root directory, CD-ROM files, etc.
> a capabilities based system. Any design that automatically gives
> CAP_SETFCAP to UID 0 is broken. A system that is put into production
> in a secure environment may not want anyone to have that power; a
Even if root must have CAP_SETFCAP, you can avoid giving anyone that
power. The solution is very simple:
root:*:0:0:root:/:/dev/null
> Overload the sticky bit if you want to go this way. It's still insecure
> if you're switching back to older kernels where setting the sticky bit
> isn't a priviledged operation,
It is totally insecure on a heterogeneous network.
The setuid bit works great. Execution on older kernels can be optionally
prevented by mangling the header.
> but at least it doesn't destroy caps for the future.
[...]
> at least doesn't cripple future development of a secure platform.
That is an odd bit of FUD.
Modern distributions can install with /usr being an NFS mount.
People expect that a backup and restore will not destry normal system
operation. If caps conflict with those, they will seldom be used.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/