Messages in this thread | | | Subject | Re: Capabilities | Date | Sun, 20 Feb 2000 21:54:28 -0300 | From | Horst von Brand <> |
| |
jmcmullan@linuxcare.com said: > Khimenko Victor <khim@sch57.msk.ru> wrote: > >[snip snip]
> > (for example now apache start with UID=0 so it has all capabilities and > > then with change of UID it'll drop all capabilities; in trusted system > > even with change of UID capabilities will retain: UID==0 is not special > > in "trusted Linux"). So system-wide option looks unavoidable :-((
> Just because I'm a frick'n idiot, why can't we bind capability > mask to UID/GIDs? That would solve a lot of the administration and > ``what happens if we mount a FAT filesystem?'' issues, IMHO.
Because the idea of capabilities is to restrict special powers to individual processes (programs) on a need to use basis. Note that this is _very_ different from the traditional Unix model, where UID 0 is all-powerful, always. It means that the special powers are handled as a set, and creating special users for each combination of capabilities is unworkable (there are currently 28 capabilities defined in the kernel).
> * UID/GID capability masks (/etc/capabilites?) would be loaded > by /sbin/init. A user with the capability (CAP_SETUCAP?) > could modify current mapping via /proc/sys/????/capabilty.
And said user can then create all-powerful processes at will, and we are back to the superuser. No dice.
> * The capabilities are only acquired on SUID or login. Ie
Which means that if root runs a random program (possibly written by the 3v17 h@x0r; or perhaps a stock program with an exploitable bug), it can take over the whole system. Exactly what capabilities were designed to prevent.
And sorry, there seems to be no easy path from here to there. No reasonable way to "switch back for a while" in sight either. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- 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/
| |