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/