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/