Messages in this thread | | | Date | Fri, 9 Apr 1999 11:03:12 -0400 (EDT) | From | parse@salem ... | Subject | capabilities in elf headers: next (final?) itteration |
| |
Hi all, I think I've got the 'Right Solution' (tm) to putting caps in elf headers in the most appropriate way (i.e., the UNIX way):
1) if capability info is in the fs, use that and ignore cap elf headers
2) otherwise, if the executable is marked setuid root in the fs, use all of forced, permitted and inheritable caps in the elf headers. This is for binaries which were formerly full-fledged setuid root; i.e., had full caps.
3) otherwise, ignore 'forced' caps in headers, but apply the permitted and inheritable bits. This way, if the prog is run by root (or a parent with full caps) it can be restrained, and any process running with elevated caps can be further restrained by anyone with write access to the executable (but can otherwise accomplish whatever the raised caps would allow).
Notes, thoughts, consequences and questions::
- 'setuid root' binaries should probably also allow setting of r/euid in the cap headers for maximum flexibility; r/euid values should be ignored w/o 'setuid root'. - there should be no need to cripple the binary for older kernels, since older kernels should ignore all cap info, and the situation is no different from before. i.e., this system doesn't require executables be made setuid root that weren't setuid root in the first place. - checking for the presence of caps in the executable should be _fast_ since under this scheme _every_ executable will be checked for caps. Of course, if the calling process has _no_ caps raised (quick & easy check), caps can be ignored for non-'setuid root' binaries.
And now for the BIG one:
- having 'root' r/euid is still powerful, since under this scheme root can create & modify setuid binaries and give them full privs (even privs that the current root-owned process doesn't have!). Thus, the ability to mark a file 'setuid root' or modify a file which is already 'setuid root' should be another capability added. With this added capability, you can completely take away the magic from a root-owned process and bring us _very_ close to the ideal situation where root isn't special and users may have elevated caps.
A big thanks to Ingo Molnar, caffeine and nicotein for putting my mind on this track; however, this scheme currently seems so perfect, that I wonder if I may have introduced a glitch by 'overclocking my CPU'. ;-)
thoughts?
- -- David L. Parsley Network Specialist City of Salem Schools
Note to RGooch: I would have cc'ed you, too, but I'm too lazy to fool with the magic number bit.
- 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/
| |