> The whole idea of capabilities is to get rid of all-powerful users, to
> split the root powers among several people where _nobody_ has all
> powers. Any scheme that keeps a root of some sort is broken.
Whoever can grant caps is in effect all-powerful.
In a pure capability model, there is no "who" can grant caps. There is
only one or more executabes who can grant caps, and which have whatever
auditing and access control checks are deemed necessary.
One thing which people often don't "get" about capabilities is that by
default capabilities are *not* inherited by child processes. If your
shell has some large set of capabilites, child processes (such as gcc or
gmake) do not get any of these capaibilities unless those executables
have capabilities flags which allow them to inherit those capabilities.
Each executable has two sets of capabilities flags: once is the set of
capabilities which will be raised when the executable is exec'ed. The
other set is the set of capabilities which the process is allowed to
inherit from the parent process. By default, both sets of capaibilities
is the null set.
So in fact, if you want to allow a user running with a privileged shell
process which has the ability to override filesystem discretional access
controls, then any programs that user might want to run to modify the
filesystem --- cp, rm, tar, mv, etc., also need capabilities set in the
executable. So configuring a capability system is much more
complicated.
- Ted
-
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/