More than the kernel. I think what we're seeing is the simple fact that the
"ideologically pure" capabilities-based system isn't going to look a whole
lot like a *ix system to programs that need to use capabilities.
However, I'll toss another suggestion into the ring. It's derived from a few
ideas that have floated by.
(1) init starts out with all capabilities, but loses all of them when it
switches out of "boot mode". This is essentially the same as the
old securelevel stuff. It also ensures that the system boot phase has
all the capabilities it needs. (Note that most boot stuff executes when
the system goes into a specific init state, i.e. has lost capabilities.)
(2) Either init or a daemon spawned by init while in "boot mode" is used to
run programs which need capabilities. This might be done explicitly, or
by giving the executables a different magic number and having the binfmt
module for that magic number pass the executable off to the daemon. (If
you support explicit pass-off, e.g. "/sbin/enabler capabilitied-exe ...",
then the binfmt loader can just exec() that enabler.)
(3) Executables with capabilities have some kind of digital signature that
can be verified by the enabler daemon. The enabler daemon verifies the
executable's integrity, then forks a subprocess which drops the
capabilities *not* used by the executable and exec()s it.
(4) How do you prevent a loop in (3) if you use a binfmt-loader? Seems
obvious: a special capability which allows bypassing the binfmt stuff.
This capability is automatically dropped when a process holding it
exec()s, so any capabilitied program run by such an enabler daemon
again will again be routed through the enabler.
The special flag for capability-enabled executables then becomes a different
magic number, without requiring any odd filesystem flags (this also allows
enabled executables to reside on filesystems which don't support Unix-style
filesystem flags, such as a SMB mount or AFS with setuid-bits disabled).
This also allows policy to be determined in user-space; if someone prefers to
use something similar to the method described for VMS (an explicit list of
enabled executables instead of a capability section in executables), they can
do so.
--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
-
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/