[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian and our frenemies of containers and userland repos



On Fri, 26 Jul 2019 at 07:34:58 +0200, Johannes Schauer wrote:
> Sadly
> this functionality requires a horribly complicated fork/syscall dance [1] which
> I also had to copy to mmdebstrap because no existing tool seemed to do it
> already.

bubblewrap might do the same dance, or at least a compatible dance?
It won't be suitable for mmdebstrap and general full-system containers
(there's only one uid and one gid in the container, with everything
visible from the host system mapped to 'nobody') but it might be suitable
for more restricted uses like building a Debian package.

> But to unshare all the namespaces, even schroot would need #898446 to be fixed.

On systems that restrict user namespace creation (Debian, Arch Linux,
RHEL), bubblewrap gets round this by being setuid root. To avoid reopening
the same security vulnerabilities that would be available via unrestricted
user namespace creation, it severely limits what it is willing to do/allow
in user-supplied code in the container, in particular setting NO_NEW_PRIVS
so that the setuid bit no longer works.

schroot is also setuid root, and sbuild relies on this to set up the
build-dependencies anyway, so in principle schroot/sbuild ought to be
able to do something like this:

- preparation step (as real root, in the chroot, with networking):
    - install build-dependencies
- either run bubblewrap or reimplement it
    - build step (as ordinary user, entering the chroot as a container,
      with no networking):
        - dpkg-buildpackage
- cleanup step (as real root, in the chroot):
    - destroy session chroot, if used

Doing that internally in schroot would require it to be actively
developed, but maybe it would be feasible to have code in sbuild that
wrapped bwrap (or even the combination of unshare(1) and setpriv(1))
around (only) the actual build step?

With the Debian Policy requirements around not writing to directories other
than /tmp, /var/tmp and the build directory, this would look something like:

    bwrap \
    --unshare-all \
    --ro-bind / / \                    # or --ro-bind /var/.../my-chroot /
    --bind /tmp /tmp \                 # or --tmpfs /tmp
    --bind /var/tmp /var/tmp \         # or --tmpfs /var/tmp
    --bind /build/hello-2.10-2 /build/hello-2.10-2 \   # or wherever the build directory is kept
    --setenv TMPDIR /tmp \
    --dev-bind /dev /dev \             # or --dev /dev for a minimal version
    --proc /proc \
    --die-with-parent \
    --chdir /build/hello-2.10-2 \
    dpkg-buildpackage

This would break any package that relies on being able to run setuid
executables (such as bwrap itself), and get privileges that way, during
its build - but perhaps that's desirable, because buildd operators
probably don't want setuid to be allowed anyway, in case it can be used
to escape the chroot?

    smcv


Reply to: