lkml.org 
[lkml]   [1999]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: capabilities in elf headers, (my) final (and shortest) iteration
From
Date
>>>>> "DP" == David L Parsley (lkml account) <kparse@salem.k12.va.us> writes:

DP> The kernel needs to be modified with the following behavior:

DP> 1) The ability to set/unset the 'cap flag' requires the capability
DP> CAP_SETFCAP to be raised, defined in linux-privs this way: 'Allows the
DP> (re)setting of a files capabilities.' Note the same applies to creating a
DP> new file, such as unpacking a tarball. This behaves almost exactly like
DP> true caps in the fs.

DP> 2) When a process attempts to set the cap flag, the kernel must read the
DP> capelf headers and check them for validity, in exactly the same manner as
DP> if the user (process) were attempting to set those caps in the fs. In
DP> this respect, my scheme is exactly like true caps in the fs, except
DP> applying to elf binaries only.

We should ensure there is nothing unrecognized in that elf
section to allow for future expandability. I'm imagining ACL's,
new privs etc now.

DP> 3) When a file has the 'cap flag' set, the kernel must treat it as
DP> immutable to prevent the owner from editing the capabilities directly in
DP> the binary.

I think rather this should be treated how we currently treat suid
bits, on write, remove them. This has 3 advanteges:
1) Since we already do it for other bits this method is well understood.
2) There is less logic involed then insuring immutability.
3) We need to do this even on capability enabled filesystems, because
we can't trust an executeable no matter how it is modified.

Actually point 3 is probably the best justification of putting this into
the executable header. A write to the executeable should nullify the capabilities
anyway.

There are 2 other places that need to be looked at:
1) Old kernels.
2) Foreign filesystems.

1) For old kernels (and to cut down on races) whatever sets the
capabilities flags should also set the ext2 immutable bit.
That way the binary will not be changed by accident.
2) We will need a nocap setting for mounting filesystems so we don't
use untrusted capabilities. Ideally this should cause the cap flag
to be hidden so interpreters like perl can't see it and implement
capabilites on their own scripts.

Just my 2 cents,
Eric

-
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:1.334 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site