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

    > [sorry if this is a resend -- i don't think it worked the first
    > time.]
    > Olaf Dietsche wrote:
    >> Andy Lutomirski <> writes:
    >>>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
    >> fi
    >> exec /sbin/init.bin "$@"
    >> ^D
    >> # chmod 755 /sbin/init
    >> # reboot
    > Wow -- I missed that. Does anyone actually do this? And is there a
    > reason why it should work like this?

    Because in kernel/sysctl.c:
    int proc_dointvec_bset(ctl_table *table, int write, struct file *filp,
    void __user *buffer, size_t *lenp)
    allows init only to set cap_bset.
    You can write a module to set cap_bset, of course, or patch the kernel
    to define CAP_INIT_EFF_SET to ~0.

    >>>cap_bprm_set_security does:
    >>>fP = fI = (new_uid == 0 || new_euid == 0)
    >>>fE = (new_euid == 0)
    >> Only if (!issecure (SECURE_NOROOT))
    >> [...]
    > I don't see any way to change securebits.

    I thought there has been a /proc way, to set securebits, but maybe I
    confused this with cap_bset. Anyway, here's the easy way out:

    diff -urN a/include/linux/securebits.h b/include/linux/securebits.h
    --- a/include/linux/securebits.h Sat Oct 5 18:42:33 2002
    +++ b/include/linux/securebits.h Sun May 23 22:38:02 2004
    @@ -1,7 +1,7 @@
    #define _LINUX_SECUREBITS_H 1

    -#define SECUREBITS_DEFAULT 0x00000000

    extern unsigned securebits;

    >> 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
    >> so.
    > I find caps to be broken, and I don't use SELinux. I want to be able
    > to run programs as non-root with limited caps, which I currently can't
    > do without modifying each program to start as root, then drop caps,
    > then set KEEPCAPS, then drop root. And even with that change, these
    > programs can't usefully exec themselves, which could be useful.

    This is, where filesystem capabilities come into play. You implemented
    them yourself. Execing is still a problem, though. However, if you
    activate SECURE_NO_SETUID_FIXUP this issue is gone, too.

    > And no, I don't think this patch is necessary, or that it should be
    > applied or used by itself. I think it makes a good starting point to
    > fix caps
    > (which a lot of people seem to think are broken).

    Well, I know, that I don't have a strong following. :-)

    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.026 / U:14.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site