[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALQRfL4_zWAp3ZUM2GXKaw_6ofEfLUGs9WypD9qi_-15MeQx0Q@mail.gmail.com>
Date: Sat, 17 Dec 2011 17:22:21 -0800
From: "Andrew G. Morgan" <morgan@...nel.org>
To: Colin Walters <walters@...bum.org>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>, serue@...ibm.com,
dhowells@...hat.com, kzak@...hat.com
Subject: Re: chroot(2) and bind mounts as non-root
On Fri, Dec 16, 2011 at 7:44 AM, Colin Walters <walters@...bum.org> wrote:
> 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).
I don't read any issues with this in your original post. What I read
there is that you want to run a build in a chroot environment. Are you
also implying that the user gets to build this chroot filesystem from
nothing - without any privileges - or are you assuming that the root
user provides some sort of template into which the user adds
build-relevant files?
If the former, then yes I think you are going to have a very hard
time. If the latter then I still don't see the core problem...
>
>> 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
> coreutils?
Before reaching that finish line, my suggestions/questions are trying
to get to the bottom of why this is believed impossible.
>
> 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/ld.so.preload. 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
> $ ./chroot-with-su.sh
> $ fcaps-chroot mychroot
> (now inside the chroot, but still uid=500)
So, you are saying that if I can explain how to prevent this from working:
> $ echo /lib64/rootshell.so > /etc/ld.so.preload
And prevent this from being possible:
> $ su -
> uid=500; euid=0; starting /bin/bash
You'll have what you want?
Or are there some other constraints not mentioned?
Thanks
Andrew
> # id
> uid=0 gid=500 groups=500
>
> The glibc linker also doesn't check that e.g. /lib64/libc.so.6 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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists