lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:4.590 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site