lkml.org 
[lkml]   [1999]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectcapabilities 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.054 / U:0.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site