Messages in this thread | | | Date | Mon, 12 Apr 1999 22:57:45 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
G. Sumner Hayes writes: > Richard Gooch writes:
>> 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/
| |