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/