linux-kernel - Re: [PATCH v2 2/2] binfmt_misc: enable sandboxed mounts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220530081358.b3tvgvo63mq5o2oo@wittgenstein>
Date:   Mon, 30 May 2022 10:13:58 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Jan Kiszka <jan.kiszka@...mens.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Laurent Vivier <laurent@...ier.eu>,
        linux-fsdevel@...r.kernel.org, Christoph Hellwig <hch@....de>,
        Kees Cook <keescook@...omium.org>,
        Sargun Dhillon <sargun@...gun.me>,
        Jann Horn <jannh@...gle.com>,
        Henning Schild <henning.schild@...mens.com>,
        Andrei Vagin <avagin@...il.com>,
        Matthew Bobrowski <repnop@...gle.com>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        containers@...ts.linux.dev,
        Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [PATCH v2 2/2] binfmt_misc: enable sandboxed mounts

On Sun, May 29, 2022 at 09:35:40PM +0200, Jan Kiszka wrote:
> On 26.12.21 14:31, Serge E. Hallyn wrote:
> > On Thu, Dec 16, 2021 at 12:26:59PM +0100, Christian Brauner wrote:
> >> From: Christian Brauner <christian.brauner@...ntu.com>
> >>
> >> Enable unprivileged sandboxes to create their own binfmt_misc mounts.
> >> This is based on Laurent's work in [1] but has been significantly
> >> reworked to fix various issues we identified in earlier versions.
> >>
> >> While binfmt_misc can currently only be mounted in the initial user
> >> namespace, binary types registered in this binfmt_misc instance are
> >> available to all sandboxes (Either by having them installed in the
> >> sandbox or by registering the binary type with the F flag causing the
> >> interpreter to be opened right away). So binfmt_misc binary types are
> >> already delegated to sandboxes implicitly.
> >>
> >> However, while a sandbox has access to all registered binary types in
> >> binfmt_misc a sandbox cannot currently register its own binary types
> >> in binfmt_misc. This has prevented various use-cases some of which were
> >> already outlined in [1] but we have a range of issues associated with
> >> this (cf. [3]-[5] below which are just a small sample).
> >>
> >> Extend binfmt_misc to be mountable in non-initial user namespaces.
> >> Similar to other filesystem such as nfsd, mqueue, and sunrpc we use
> >> keyed superblock management. The key determines whether we need to
> >> create a new superblock or can reuse an already existing one. We use the
> >> user namespace of the mount as key. This means a new binfmt_misc
> >> superblock is created once per user namespace creation. Subsequent
> >> mounts of binfmt_misc in the same user namespace will mount the same
> >> binfmt_misc instance. We explicitly do not create a new binfmt_misc
> >> superblock on every binfmt_misc mount as the semantics for
> >> load_misc_binary() line up with the keying model. This also allows us to
> >> retrieve the relevant binfmt_misc instance based on the caller's user
> >> namespace which can be done in a simple (bounded to 32 levels) loop.
> >>
> >> Similar to the current binfmt_misc semantics allowing access to the
> >> binary types in the initial binfmt_misc instance we do allow sandboxes
> >> access to their parent's binfmt_misc mounts if they do not have created
> >> a separate binfmt_misc instance.
> >>
> >> Overall, this will unblock the use-cases mentioned below and in general
> >> will also allow to support and harden execution of another
> >> architecture's binaries in tight sandboxes. For instance, using the
> >> unshare binary it possible to start a chroot of another architecture and
> >> configure the binfmt_misc interpreter without being root to run the
> >> binaries in this chroot and without requiring the host to modify its
> >> binary type handlers.
> >>
> >> Henning had already posted a few experiments in the cover letter at [1].
> >> But here's an additional example where an unprivileged container
> >> registers qemu-user-static binary handlers for various binary types in
> >> its separate binfmt_misc mount and is then seamlessly able to start
> >> containers with a different architecture without affecting the host:
> >>
> >> root    [lxc monitor] /var/snap/lxd/common/lxd/containers f1
> >> 1000000  \_ /sbin/init
> >> 1000000      \_ /lib/systemd/systemd-journald
> >> 1000000      \_ /lib/systemd/systemd-udevd
> >> 1000100      \_ /lib/systemd/systemd-networkd
> >> 1000101      \_ /lib/systemd/systemd-resolved
> >> 1000000      \_ /usr/sbin/cron -f
> >> 1000103      \_ /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
> >> 1000000      \_ /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers
> >> 1000104      \_ /usr/sbin/rsyslogd -n -iNONE
> >> 1000000      \_ /lib/systemd/systemd-logind
> >> 1000000      \_ /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220
> >> 1000107      \_ dnsmasq --conf-file=/dev/null -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --liste
> >> 1000000      \_ [lxc monitor] /var/lib/lxc f1-s390x
> >> 1100000          \_ /usr/bin/qemu-s390x-static /sbin/init
> >> 1100000              \_ /usr/bin/qemu-s390x-static /lib/systemd/systemd-journald
> >> 1100000              \_ /usr/bin/qemu-s390x-static /usr/sbin/cron -f
> >> 1100103              \_ /usr/bin/qemu-s390x-static /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-ac
> >> 1100000              \_ /usr/bin/qemu-s390x-static /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers
> >> 1100104              \_ /usr/bin/qemu-s390x-static /usr/sbin/rsyslogd -n -iNONE
> >> 1100000              \_ /usr/bin/qemu-s390x-static /lib/systemd/systemd-logind
> >> 1100000              \_ /usr/bin/qemu-s390x-static /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220
> >> 1100000              \_ /usr/bin/qemu-s390x-static /sbin/agetty -o -p -- \u --noclear --keep-baud pts/0 115200,38400,9600 vt220
> >> 1100000              \_ /usr/bin/qemu-s390x-static /sbin/agetty -o -p -- \u --noclear --keep-baud pts/1 115200,38400,9600 vt220
> >> 1100000              \_ /usr/bin/qemu-s390x-static /sbin/agetty -o -p -- \u --noclear --keep-baud pts/2 115200,38400,9600 vt220
> >> 1100000              \_ /usr/bin/qemu-s390x-static /sbin/agetty -o -p -- \u --noclear --keep-baud pts/3 115200,38400,9600 vt220
> >> 1100000              \_ /usr/bin/qemu-s390x-static /lib/systemd/systemd-udevd
> >>
> >> [1]: https://lore.kernel.org/all/20191216091220.465626-1-laurent@vivier.eu
> >> [2]: https://discuss.linuxcontainers.org/t/binfmt-misc-permission-denied
> >> [3]: https://discuss.linuxcontainers.org/t/lxd-binfmt-support-for-qemu-static-interpreters
> >> [4]: https://discuss.linuxcontainers.org/t/3-1-0-binfmt-support-service-in-unprivileged-guest-requires-write-access-on-hosts-proc-sys-fs-binfmt-misc
> >> [5]: https://discuss.linuxcontainers.org/t/qemu-user-static-not-working-4-11
> >>
> >> Link: https://lore.kernel.org/r/20191216091220.465626-2-laurent@vivier.eu (origin)
> >> Link: https://lore.kernel.org/r/20211028103114.2849140-2-brauner@kernel.org (v1)
> >> Cc: Sargun Dhillon <sargun@...gun.me>
> >> Cc: Serge Hallyn <serge@...lyn.com>
> > 
> > (one typo below)
> > 
> > Acked-by: Serge Hallyn <serge@...lyn.com>
> > 
> 
> What happened to this afterwards? Any remaining issues?

Not that we know. I plan to queue this up for 5.20.