[lkml]   [2011]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: chroot(2) and bind mounts as non-root
    On Thu, 2011-12-15 at 10:55 -0800, Andrew G. Morgan wrote:
    > I'm genuinely confused whether all these concerns are valid with file
    > capabilities.
    > Consider (let's say luser is some user that I want to be active inside
    > the chroot, but I don't want to allow regular login to my system):

    Then we already have different deployment scenarios. You seem to be
    imagining a system where some user has an environment preconfigured by a
    system administrator. My constraint (read my previous posts) is that
    the functionality must be available "out of the box" on a mainstream
    "distro" such as RHEL or Debian to any uid. I don't even want to
    require addition to some magical group (that in reality is often a root
    backdoor anyways).

    > root> setcap cap_sys_chroot=ep /tmp/launcher
    > Is there a need for privileged binaries within /tmp/chroot? If not,
    > how might they get there (without help from root, always presuming I
    > can prevent luser from logging in outside of this chroot'd
    > environment)?

    First of all, as I mentioned in my original mail (and is still in the
    Subject line), chroot(2) *almost* gets me what I want - except I need
    the ability to at least mount /proc, and being able to do bind mounts is
    necessary to use /dev.

    But let's just ignore the bind mounts for a second and pretend
    cap_sys_chroot is enough. Is your suggestion that we could distribute a
    copy of /usr/sbin/chroot that grants cap_sys_chroot via file caps a
    secure thing to add to util-linux? Or we could just add it to

    See the attached shell script for an attack that should work against
    *any* setuid binary that uses glibc. I wrote this without looking at
    other exploits on the internet, just reading the glibc sources - mainly
    for my own edification.

    It turns out in this case glibc trusts the contents of /etc, and in
    particular /etc/ So all I need to do is make a shared
    library that just runs /bin/bash as a __attribute__ ((constructor)), and
    when the glibc dynamic linker is loading /bin/su that I've hardlinked
    into the chroot, game over:

    $ cp /usr/sbin/chroot /usr/local/bin/fcaps-chroot
    $ sudo setcap cap_sys_chroot=ep /usr/local/bin/fcaps-chroot
    $ ./
    $ fcaps-chroot mychroot
    (now inside the chroot, but still uid=500)
    $ echo /lib64/ > /etc/
    $ su -
    uid=500; euid=0; starting /bin/bash
    # id
    uid=0 gid=500 groups=500

    The glibc linker also doesn't check that e.g. /lib64/ is owned
    by root - clearly I could just replace that with whatever I want. But
    this is less typing. Note glibc isn't buggy here, it was designed in a
    world where unprivileged users can't chroot.

    [unhandled content-type:application/x-shellscript]
     \ /
      Last update: 2011-12-16 16:47    [W:0.030 / U:31.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site