We now rely on PR_SET_NO_NEW_PRIVS, so make that clearer.  The old
comment around uid 0 for `SECBIT_NOROOT` was actually wrong, because
we always setuid back to the calling user.

By default, we had supported `--mount-bind /dev /dev` to get
access to devices.  But in many cases, build systems and the
like will want to avoid exposing host physical devices.

For example, if I'm building something locally, I don't want the
makefile etc. to be able to access `/dev/dri`.

This was just a hack which worked around a RHEL6 kernel bug.  I no
longer care about RHEL6; linux-user-chroot is now just RHEL7 only.

It's also been a CVE source, although longer in the past.  Having it
can make exploiting race conditions and such easier.

seccomp is disabled by default for backwards compatibility.

This "v0" version is a basic blacklist that turns off some of the
known historical attack surface, initially imported from xdg-app.

I added a note about code sharing - we should share rules among
container implementations.

I took this from xdg-app.

So sadly, I screwed up the invocation of `prctl(PR_SET_NO_NEW_PRIVS` -
we need to provide 0 for the remaining arguments, otherwise the
kernel will *always* give us `-EINVAL`.

I didn't notice this at the time because I wanted to support the RHEL6
kernel.  Anyways, I no longer care about RHEL6 myself, and I'm going
to declare no one else should either =)

 - Note to use ostree-list for submissions
 - Link to Codethink's sandbox lib
   https://mail.gnome.org/archives/ostree-list/2015-June/msg00002.html
 - Talk more about how other build
   systems root setups work and why l-u-c is unique, etc.

The Baserock people were hitting up against the limit of 50, which as
the newly added comment says isn't really effective against DoS
anyways, so let's just bump it up significantly.

Tested-by: Lars Wirzenius <lars.wirzenius@codethink.co.uk>

Otherise, the user can access otherwise inaccessible directories like
this:

$ linux-user-chroot --mount-bind /root/.virsh ~/mnt / /bin/sh

Also, we should check the accessibility of the chroot target; this is
much harder to exploit because you'd need an executable inside the
chroot that can be run.

Reported-by: Marc Deslauriers <marc.deslauriers@canonical.com>
Reported-by: Ryan Lortie <desrt@desrt.ca>
Reviewed-by: Marc Deslauriers <marc.deslauriers@canonical.com>
Signed-off-by: Colin Walters <walters@verbum.org>

Otherwise, the user can access otherwise inaccessible directories like:

$ linux-user-chroot --chdir /root/.virsh / /bin/sh

Reported-by: Ryan Lortie <desrt@desrt.ca>
Reported-by: Marc Deslauriers <marc.deslauriers@canonical.com>

So we will do the right thing on 32 bit.

Otherwise the MS_MOVE call aborts.

chroot() breaks some tools that expect / to be an actual mount point.
Doing namespace manipulation is cleaner than chroot().

See http://lists.freedesktop.org/archives/systemd-devel/2012-September/006703.html
"[systemd-devel] OSTree mount integration"

This happens when run recursively.

This flag is exactly what we want for this tool (it's what I thought
SECBIT_NOROOT did).

See the linked discussion from here:

http://lwn.net/Articles/504879/

Lars Wirzenius authored Apr 24, 2012 and Colin Walters committed Apr 24, 2012

Commit message and build rules written by
Colin Walters <walters@verbum.org>.

Reviewed-by: Colin Walters <walters@verbum.org>

Richard Maw authored Apr 18, 2012 and Colin Walters committed Apr 18, 2012

Signed-off-by: Colin Walters <walters@verbum.org>

Suggested by Owen Taylor <otaylor@redhat.com>

Some versions of the Linux kernel require large (order 4) contiguous
allocations per network namespace.  This optional helper program is a
workaround for that; one can create the empty network namespace just
once.

For some reason the RHEL6 kernel-headers package doesn't have it.

Let's just follow for now the cargo culting of "define defines ourself
if not available" that various kernel-tied utilities have because
various buildsystems are too shitty to make it easy to install newer
kernel headers even if you're running an old kernel.

It was just an extra check to be sure we would be switching back to
the right uid, but there's no reason not to allow executing this
program as root.