Messages in this thread | | | Date | Tue, 13 Apr 1999 01:18:07 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
David L. Parsley (kparse@salem.k12.va.us) > On Sun, 11 Apr 1999, Pavel Machek wrote: > >> You do not want this kind of support in kernel. Believe me. >> Better use setuid0 as marker (those are already immutable) and >> userspace suid program which implements your CAP_SETFCAP. > > This applies just as well to the sticky bit solution; if it's not > feasible to have the kernel check the caps in the file when setting > the cap flag, you could still have a userspace util that did all > the real work. Good idea!
I'm doing that just now.
The code is privileged (currently setuid-root), so it takes a long time to write. Sometimes it looks like I have more error checking code than productive code.
Policy is determined by a config file. Liberal admins can let users make setuid-root executables. :-)
Files become setuid-root. The executable header gets mangled, unless the executable is already setuid-root.
Currently, you would use a specification file like this:
^^TypeA^^ fP CAP_SYS_RESOURCE CAP_SYS_RAWIO / Room for 128 bits, but only fE / 64 can be used with existing code. fI CAP_NET_BROADCAST RUID RUID EUID RUID SUID RUID FUID RUID RGID RGID EGID games SGID uucp FGID RGID groups games uucp mail
I could add some sort of extended access control to that. I could add a minimum capability requirement, so that execution fails if the post-exec capabilities are not enough to complete execution.
There is also a shortcut method that lets you specify capabilities on the command line. (all 3 fields get the same content -- reasonable?)
I've saved ELF hacking for last. Hopefully I won't need to write my own ELF support code. (Help!) I don't trust libraries too much, since I don't want to see my code posted to Bugtraq.
As usual, all code is under the LGPL.
- 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/
| |