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).
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.
As far as I can tell, unprivileged chroot() would expose far less
new attack surface than full unprivileged namespaces support
and would still be usable for lightweight linux-in-linux stuff
(similar to fakechroot, although it wouldn't allow you to keep
procfs, so maybe it wouldn't be sooo useful for that) and,
more importantly IMO, it would allow adding sandboxing to
programs that, while not perfect, "just works" across distros
if the kernel is new enough, doesn't change uid mappings, is
mostly reliable when used together with seccomp (apart from the
case where folders are moved out of the chroot) and doesn't
require the use of special APIs everywhere.
(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.)
Attachment:
signature.asc
Description: Digital signature
