Re: [PATCH] fs: allow unprivileged chroot()

[Jann Horn <jann@thejh.net>]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

On Mon, Jan 04, 2016 at 02:51:37AM +0100, Richard Weinberger wrote:
> Am 04.01.2016 um 02:39 schrieb Jann Horn:
> > On Sun, Jan 03, 2016 at 12:09:36PM +0100, Richard Weinberger wrote:
> >> On Sat, Jan 2, 2016 at 8:52 AM, Jann Horn <jann@thejh.net> wrote:
> >>> Allow unprivileged processes to chroot() themselves, under the
> >>> following conditions:
> >>>
> >>>  - The caller must have set NO_NEW_PRIVS to prevent him from
> >>>    invoking setuid/setgid/setcap executables in the chroot that
> >>>    could be tricked into opening files from the chroot.
> >>>  - The fs_struct must not be shared to prevent the caller from
> >>>    chrooting another process that does not have NO_NEW_PRIVS
> >>>    active.
> >>>  - chroot() is sometimes (mis-)used for sandboxing purposes.
> >>>    To prevent a simple chroot breakout using e.g. the
> >>>    double-chroot trick (chdir("/"), chroot("/foo"),
> >>>    chroot("../../../../../../../../")), require the process to
> >>>    be un-chrooted before performing chroot()
> >>
> >> What is the use case?
> >> If you want to jail yourself as non-root you can create a new user and
> >> mount namespace.
> >> Then you're allowed to change root.
> > 
> > Yes, on a normal vanilla kernel with a standard config, that works
> > with just a new user namespace.
> > 
> > There are a lot of systems with kernels that require caps for
> > CLONE_NEWUSER by default because of distro patches (e.g. Debian
> > and grsecurity) or that disable namespaces entirely (e.g. Android).
> 
> Well, let us focus on vanilla kernels.

Okay. Yeah, true, it's not so useful on vanilla kernels.


> > AFAIK Debian and grsecurity do it because from a security
> > perspective, unprivileged namespaces are pretty scary and likely
> > to still contain a bunch of unfixed issues.
> 
> FUD

It's not. :D


> > (Maybe I should send another patch for a user namespace flag
> > that causes the namespace to have its parent's uid mappings from
> > the perspective of processes inside it, but its real uid mappings
> > from the kernel's perspective? That would, on vanilla kernels,
> > at least allow unprivileged fileserver processes or so to sandbox
> > themselves using user+mount namespaces without losing the ability
> > to identify file owners and groups.)
> 
> Sounds promising. :-)

I'll try that tomorrow.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]