Messages in this thread | | | Date | Sun, 11 Apr 1999 14:52:20 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | capabilities in elf headers, (my) final (and shortest) iteration |
| |
Hi all, Many of you have brought up many valid arguments with respect to putting capabilities in the elf headers. This has caused my thinking to change over time, for instance I no longer think a capability-enabled binary should be marked setuid root. It was just too ugly. I think my current approach to this is quite close to true capabilities in the fs, if only for elf binaries. For each point in my specification, I'll compare and contrast my solution with real caps in the fs. The good news is, this has gotten a bit shorter.
Currently, the kernel makes no use of the 'sticky bit' on files (though it does on directories). I think an excellent use for this bit would be for marking elf executables as capability enabled. For this to work exactly as capabilities in the fs would, we have to modify kernel behavior a bit. From here on out I will refer to the 'sticky bit' as the 'cap flag'. The cap-elf headers should contain all three of the 128-bit capability sets; permitted, inheritable, and effective.
The kernel needs to be modified with the following behavior:
1) The ability to set/unset the 'cap flag' requires the capability CAP_SETFCAP to be raised, defined in linux-privs this way: 'Allows the (re)setting of a files capabilities.' Note the same applies to creating a new file, such as unpacking a tarball. This behaves almost exactly like true caps in the fs.
2) When a process attempts to set the cap flag, the kernel must read the capelf headers and check them for validity, in exactly the same manner as if the user (process) were attempting to set those caps in the fs. In this respect, my scheme is exactly like true caps in the fs, except applying to elf binaries only.
3) When a file has the 'cap flag' set, the kernel must treat it as immutable to prevent the owner from editing the capabilities directly in the binary. The user must first un-set the flag (checked exactly as if they were removing all caps in the fs), then modify caps, then attempt to re-set as in (2). This differs significantly from true caps in the fs, although this sort of behavior might be advantageous in a caps system: consider a black hat who remotely logs in as some user; since the login is remote, likely no caps should be raised. But if that user owns a binary with a set of permitted caps, the black hat could modify the binary to do Evil Things (tm).
Other than these three changes, I see no good reason why this wouldn't give us near-complete capabilities support _now_, with the ability to get rid of root and all. As a suggestion, 'root magic' in the kernel should also be a configurable option, so old, unmodified root behavior can be maintained during transition.
OK, folks: lay it on me. thoughts, flames, what have you.
- -- David L. Parsley Network Specialist City of Salem Schools
- 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/
| |