[lkml]   [1999]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Subject: Re: ext3 to include capabilities?
    Santos Halpar writes:
    > Albert D. Cahalan" <> wrote:
    >> G. Sumner Hayes writes:
    >>> Albert Cahalan <> wrote:

    >>>> 1. Put capabilities information in the executable header.
    >>>> 2. Mark the executable setuid root.
    >>>> 3. Have the kernel check for #1 if #2, and prefer #1 if present.
    >>> Of course, you've completely busted up security.
    >> Nope, think about the system a bit more. It isn't so stupid.
    >> if(setuid){
    >> if(root_owned && cap_header) use_cap_header();
    >> else use_setuid_bit();
    >> }
    > I understand that. Read my concern again. I don't understand how
    > your system can possibly make my (already installed) 2.0.x kernel
    > ignore the setuid bit. I have 2.0.x around for stability, so putting
    > random patches into it isn't really an option. It seems like your
    > system will run programs with capabilities on 2.2.x but full-blown
    > setuid on 2.2.x,

    One doesn't give capabilities to random executables. One uses them
    in place of existing setuid-root settings. Consider this program:

    -rwsr-xr-x 1 root root 14148 Jan 10 1998 /bin/ping

    Right now it is setuid-root, with full capabilities.
    With my proposal, it gets far fewer capabilities.
    If you revert to the old kernel, you should get the old security.

    You really need a setuid-root setting that is ignored by newer
    kernels, so that you can still run an old kernel with traditional
    security. Without this, /bin/ping and others won't run on old kernels.

    > which opens up the security holes I'm concerned about
    > when running the most stable (for the moment :) and secure kernel.

    No, you get back the old holes (if any) when you run an old kernel.

    > Same thing with mount; I never let /bin/mount be suid, but I'd be
    > willing to give it a mount capability (if there were one; full
    > admin capability is a bit too much for my taste). So when 2.?3?.x
    > is running, peons could mount/umount the floppy; with 2.0.x it'd be
    > like it is now -- no mounting for non-root.

    Of course, a buffer overflow would still grant root and full
    capabilities. (mount an ext2 floppy with privileged executables)

    BTW, this is Red Hat 5.0 mount:
    -rwsr-xr-x 1 root root 34424 Jan 10 1998 /bin/mount

    > Basically, it seems like your system doesn't allow a secure fallback
    > for 2.0.x machines. It promotes capabilities-having bins to suid
    > ones under old kernels, which is a major bug IMO.

    It is a minor missing feature. You should not grant capabilities
    to executables you don't trust, and you should not run crummy
    old kernels. I had indeed assumed that you would only be reducing
    the capabilities that current setuid-root executables have, not
    granting capabilities to new poorly-trusted executables.

    When replacing setuid-root with capabilities, you certainly do
    want a fallback to the old setuid-root system.

    > Your idea does limit the fs data needed to one bit, and that's
    > something I don't mind. Using the suid bit as you suggest is
    > bogus, though. The sticky bit would work if it were limited to root,
    > but that's not an assumption that's workable in an NFS environment
    > (correct me if I'm wrong).

    The sticky bit would work fine over NFS. In that case, there must be
    a header flag to disable setuid operation. This is because /bin/ping
    and others must be setuid-root when running with an old kernel, but
    should not be root when they can just get the needed capabilities.

    I prefer the setuid bit though, because it will be noticed by scripts
    that look for suspicious executables. It is much less likely that a
    script will notice an executable with the sticky bit set. (but this
    is still better than a strange new file attribute)

    Well, which do people prefer? (sticky bit or setuid bit)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.028 / U:29.612 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site