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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:26 EST