[lkml]   [2004]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] scaled-back caps, take 4
    Andy Lutomirski <> writes:

    > You don't like my patch because it rips out a bunch of code and it's
    > not clear it won't break stuff.
    > I don't like your patch because it takes a bunch of incomprehensible
    > code that does almost nothing and tweaks it slightly to do something
    > useful. (That's not to say it's does the wrong thing; I just don't
    > think the code is clear.)
    > So I decided to figure out what was going on with the original code.
    > First, CAP_SETPCAP is never obtainable (by anything).
    > Since cap_bset never has this bit set, nothing can inherit it
    > from fP. capset_check prevents it from getting set in pI.

    # mv /sbin/init /sbin/init.bin
    # cat >/sbin/init
    #! /bin/sh

    if test $$ -eq 1; then
    mount /proc
    echo -1 >/proc/sys/kernel/cap-bound

    exec /sbin/init.bin "$@"
    # chmod 755 /sbin/init
    # reboot

    > Second, cap_bset is broken. For one thing, there's no way
    > to remove the caps you want to restrict from already-running
    > tasks. So I don't think it matters if we break/change it.

    Maybe I don't understand this, but I think this is what sys_capset()
    is for.

    > cap_bprm_set_security does:
    > fP = fI = (new_uid == 0 || new_euid == 0)
    > fE = (new_euid == 0)

    Only if (!issecure (SECURE_NOROOT))

    > The whole result is just
    > pP' = (uid == 0 || euid==0) & X
    > pE' = (euid == 0) & X
    > This patch implements this. It should be invisible to userspace
    > (unless userspace (ab)uses cap_bset). It also adds a secureexec
    > flag, which we both need.
    > First, did I get this right? It seems to work :)

    With this patch you effectively revert all capable() calls back to
    suser() tests. If this is what you intended, your patch looks fine.

    > Second, do you have any objection to both of us redoing our
    > patches against this one? It should make them nicer-looking
    > at least.

    I didn't scrutinize capabilities as thoroughly as you did, but I still
    don't see why your patch is necessary, besides the changes in
    fs/exec.c and include/binfmts.h, maybe.

    $ cp commoncap.c lutocap.c
    modify it to your liking
    # insmod lutocap

    same goes for chriscap.c

    Please, don't get me wrong. For me, it's just a matter of maintaining
    a slightly bigger fscaps patch. But I don't think capabilities in
    Linux are really broken, only because some proponents of SELinux claim

    If you want a simpler - setuid like - capabilities model, throw out
    the inheritable _and_ permitted set and use the effective set alone.

    Regards, Olaf.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.024 / U:18.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site