lkml.org 
[lkml]   [2004]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Capability problems in 2.6.1?
    On Tue, Jan 13, 2004 at 04:17:37PM -0800, Chris Wright wrote:
    > * andrewg@felinemenace.org (andrewg@felinemenace.org) wrote:
    > > Hello,
    > >
    > > I seem to be having problems with getting capabilities to work
    > > correctly under 2.6.1. This is the code I'm using to drop it with.
    >
    > I'm aware of one bug here. However, I'm not entirely sure what bug
    > you're trying to report. Specifically, you show the cap_eff values
    > (which appear inconsistent) as well as saying operations perform fine in
    > each case. Does this mean you are allowed to mount when you took away
    > CAP_SYS_ADMIN (buggy) or that you were properly denied?

    I'm reporting that mount worked find when CAP_SYS_ADMIN was taken away.

    Whats buggy about it? :

    >
    > > #define HIGHSEC (CAP_TO_MASK(CAP_FOWNER) | CAP_TO_MASK(CAP_LINUX_IMMUTABLE) |\
    > > CAP_TO_MASK(CAP_NET_ADMIN) | CAP_TO_MASK(CAP_SYS_MODULE) |\
    > > CAP_TO_MASK(CAP_SYS_RAWIO) | CAP_TO_MASK(CAP_SYS_PACCT) |\
    > > CAP_TO_MASK(CAP_SYS_ADMIN) | CAP_TO_MASK(CAP_SYS_BOOT) |\
    > > CAP_TO_MASK(CAP_SYS_TIME) | CAP_TO_MASK(CAP_NET_RAW) |\
    > > CAP_TO_MASK(CAP_SYS_TTY_CONFIG) | CAP_TO_MASK(CAP_IPC_OWNER) |\
    > > CAP_TO_MASK(CAP_KILL) | CAP_TO_MASK(CAP_SETPCAP) |\
    > > CAP_TO_MASK(CAP_NET_BROADCAST) | CAP_TO_MASK(CAP_SYS_CHROOT) |\
    > > CAP_TO_MASK(CAP_SYS_PTRACE) | CAP_TO_MASK(CAP_SYS_NICE) |\
    > > CAP_TO_MASK(CAP_SYS_RESOURCE) | CAP_TO_MASK(CAP_MKNOD))
    > >
    > > if(current->pid != 1) {
    > > printk(KERN_INFO "sys_chroot(%s): HIGHSEC mask: %08x, cap_permitted: %08x, cap_inheritable: %08x, cap_effective: %08x\n", filename, HIGHSEC, current->cap_permitted, current->cap_inheritable, current->cap_effective);
    > >
    > > current->cap_permitted = cap_drop(current->cap_permitted, HIGHSEC);
    > > current->cap_inheritable = cap_drop(current->cap_inheritable, HIGHSEC);
    > > current->cap_effective = cap_drop(current->cap_effective, HIGHSEC);
    > >
    > > printk(KERN_INFO "sys_chroot(%s): HIGHSEC mask: %08x, cap_permitted: %08x, cap_inheritable: %08x, cap_effective: %08x\n", filename, HIGHSEC, current->cap_permitted, current->cap_inheritable, current->cap_effective);
    > >
    > > }
    >
    > I assume this is code you added to sys_chroot().
    >
    > > To test, I chroot a process, and check the /proc/self/status flag, and attempt
    >
    > Do you have your own test process that calls chroot(2) itself, or are you
    > using chroot(1) (which will do an execve(2)). If you are doing the
    > latter, the execve(2) basically resets the capabilities.

    Okay, so why would the capabilities show to be masked out? I have been using
    chroot + execve. I'll write a test program later, and report.

    >
    > > mounting/dismounting a filesystem (which should fail, since we are taking
    > > CAP_SYS_ADMIN away.). I've tried various combinations of LSM selections, but
    > > this doesn't seem to help. I edited capability.h to change the effective set
    > > had SET_PCAP. (Yes, I realise I should set the allowed capabilities ;) not the
    > > opposite)
    >
    > OK, so all the 0xffffffff below reflect the added CAP_SETPCAP (typically it'd
    > be 0xfffffeff).
    >
    > > CONFIG_SECURITY=n
    > > Causes the chrooted process mask to be 0xffffffff, and operations are
    > > performed fine.
    >
    > OK, w/out CONFIG_SECURITY you have created a kernel that is most like
    > the 2.4 kernels with capabilities built in.
    >
    > >
    > > CONFIG_SECURITY=y
    > > Causes the chrooted process mask to be 0xf00044d7, and operations are
    > > performed fine.
    >
    > This means you are just using the default LSM hooks, which (as of now)
    > don't care about any of the cap_* fields.
    >
    > > CONFIG_SECURITY=y && CONFIG_SECURITY_CAPABILITIES=m
    > > When unloaded:
    > > Causes the chrooted process mask to be 0xf00044d7, and
    > > operations are preformed fine.
    >
    > using default hooks, as above.
    >
    > > When loaded:
    > > Causes the chrooted process mask to be 0xffffffff, and
    > > operations are preformed fine.
    >
    > capabilities installed, execve() will reset the cap_* fields.
    >
    > > When unloaded:
    > > Causes the chrooted process mask to be 0xf00044d7, and
    > > operations are preformed fine. (I made sure capability and
    > > common cap where removed.)
    >
    > using default hooks.
    >
    > > When just commoncap is loaded:
    > > Causes the chrooted process mask to be 0xf00044d7, and
    > > operations are preformed fine.
    >
    > ditto.
    >
    > > CONFIG_SECURITY=y && CONFIG_SECURITY_CAPABILITIES=y
    > > Causes the chrooted process mask to be 0xffffffff, and operations are
    > > performed fine.
    >
    > capabilities installed, execve() will reset the cap_* fields.
    >
    > > It also appears securebits.h has something to do with the whole thing as well,
    > > but I don't know. If I've missed something that causes capabilities to work in
    > > the 2.4 (or how I remember :/) series, I'd appreciate it if anyone could
    > > point it out.
    >
    > The cases where you have capabilities loaded are behaving the same as
    > 2.4.

    Okay, thats good to know. I notice in securebits.h, there is SECURE_NOROOT
    and SECURE_NO_SETUID_FIXUP, can they do what I'd like (capabilities are
    transferred across execve, and aren't dropped? If so, how I can use it?

    >
    > > Otherwise, does it look like this is a bug, and possibly a bad one since
    > > people could/would assume it would work the same as 2.4, and there previously
    > > capability restricted binds and wu-ftpds are now open?
    >
    > Those will rely on capset(2) which will (should) return an error from
    > modules that don't support the interface.
    >
    > thanks,
    > -chris
    > --
    > Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

    Thanks,
    Andrew Griffiths
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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