Messages in this thread | | | Date | Fri, 9 Apr 1999 10:55:00 -0700 (PDT) | From | Jonathan Walther <> | Subject | Re: capabilities in elf headers: next (final?) itteration |
| |
Sounds cool, but how do you plan to let other users have "raised caps"? Maybe there should be a capabilities section in /etc/password that shows a users capabilities? And root of couse gets his all turned on... or something like that.
Jonathan
On Fri, 9 Apr 1999 parse@salem.k12.va.us wrote:
> 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/ >
- 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/
| |