Messages in this thread | | | Date | Tue, 13 Apr 1999 08:28:58 +1000 | From | Richard Gooch <> | 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.
Sorry, I think you're wrong.
> 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 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 reboot into a less secure configuration may be > required to play with root-like powers.
This to me is one of the real blind-spots of some people who are pushing capabilities. There is absolutely no need to remove the privileges of the root account. By default root has all capabilities.
Think about it: you will need *some* account* with the abilility to grant caps anyway. So root is it.
The major practical benefit that capabilities provide is that you can have privileged binaries that have *only* the privileges that they need, and no more. Having a root account with full privileges is completely orthogonal to this.
> The separation of powers and UIDs is one of the driving forces > behind capabilities. All efforts to support capabilities must be > made with the eventual elimination of special-case-for-uid-0 in the > kernel as a possibility. Not a likely thing to do tomorrow or next > year, but keep the general motion in that direction. Most users > will give the root account UID 0 and all capabilities, so things > will look pretty transparent to the end-user who doesn't want to > bother with better-thought-out/more-draconian(depending on your POV) > policies, but the idea is to make the security policy more flexible.
Capabilities are a good thing, as they give more flexibility. But there simply is no need to cripple root.
> 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, but at least it doesn't > destroy caps for the future. You'll have to cope with things like > emacs that think the sticky bit still has antiquated meanings, but > that at least doesn't cripple future development of a secure > platform.
Overloading the sticky bit is completely flawed, *because* it is not universally restricted. Using it would open up a whopping great big security hole. Therefore it must not be overloaded.
Regards,
Richard....
- 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/
| |