Messages in this thread | | | Subject | Re: caps in elf, next itteration (the hack get's bigger) | Date | Tue, 13 Apr 1999 18:36:46 -0400 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <Pine.LNX.4.10.9904130826200.22296-100000@tahallah.demon.co.uk>, Ale x Buell writes: +----- | Been following this thread. | | Looks like lots of problems to work through to implement capabilities in | the kernel and filesystems. | | In that case, perhaps you all would be better off writing a new kernel | from the ground upwards to include capabilities. +--->8
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/
| |