Messages in this thread | | | Subject | Re: capabilities in elf headers, (my) final (and shortest) iteration | From | (Eric W. Biederman) | Date | 12 Apr 1999 00:34:23 -0500 |
| |
>>>>> "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/
| |