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@xxxxxxxxx> 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:
signature.asc
Description: Digital signature
