Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 12/3/25 07:43, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>> This means that a breach of crosvm is not guaranteed to be fatal.
>>>
>>> The Wayland socket is still only accessible by root, so crosvm must run
>>> as root.  The known container escape via /proc/self/exe is blocked by
>>> bwrap being on a read-only filesystem.  Container escapes via /proc are
>>> blocked by remounting /proc read-only.  Crosvm does not have
>>> CAP_SYS_ADMIN so it cannot change mounts.
>>>
>>> The two remaining steps are:
>>>
>>> - Run crosvm as an unprivileged user.
>>> - Enable seccomp to block most system calls.
>>>
>>> The latter should be done from within crosvm itself.
>>>
>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
>>> ---
>>>  host/rootfs/default.nix                            |  4 ++--
>>>  .../template/data/service/vhost-user-gpu/run       | 24 +++++++++++++++++++++-
>>>  2 files changed, 25 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/host/rootfs/default.nix b/host/rootfs/default.nix
>>> index ca2084f26d58be5e0e1695634e125032c50f82b2..4716bb7298515b2940cad09bb55e42c196ce7ebc 100644
>>> --- a/host/rootfs/default.nix
>>> +++ b/host/rootfs/default.nix
>>> @@ -10,7 +10,7 @@ pkgsMusl.callPackage (
>>>  
>>>  { spectrum-host-tools, spectrum-router
>>>  , lib, stdenvNoCC, nixos, runCommand, writeClosure, erofs-utils, s6-rc
>>> -, btrfs-progs, busybox, cloud-hypervisor, cosmic-files, crosvm
>>> +, btrfs-progs, bubblewrap, busybox, cloud-hypervisor, cosmic-files, crosvm
>>>  , cryptsetup, dejavu_fonts, dbus, execline, foot, fuse3, iproute2
>>>  , inotify-tools, jq, kmod, mdevd, mesa, mount-flatpak, s6
>>>  , s6-linux-init, socat, systemd, util-linuxMinimal, virtiofsd
>>> @@ -25,7 +25,7 @@ let
>>>      trivial;
>>>  
>>>    packages = [
>>> -    btrfs-progs cloud-hypervisor cosmic-files crosvm cryptsetup dbus
>>> +    btrfs-progs bubblewrap cloud-hypervisor cosmic-files crosvm cryptsetup dbus
>>>      execline fuse3 inotify-tools iproute2 jq kmod mdevd mount-flatpak s6
>>>      s6-linux-init s6-rc socat spectrum-host-tools spectrum-router
>>>      util-linuxMinimal virtiofsd xdg-desktop-portal-spectrum-host
>>> diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run
>>> index 0b4f6a00bc7aed0e721454d584d3bcd47fb18e2a..9b5dfad91944bd2c6c8994f387ab91394c68c1df 100755
>>> --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run
>>> +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run
>>> @@ -1,10 +1,32 @@
>>>  #!/bin/execlineb -P
>>>  # SPDX-License-Identifier: EUPL-1.2+
>>>  # SPDX-FileCopyrightText: 2025 Alyssa Ross <hi@alyssa.is>
>>> +# SPDX-FileCopyrightText: 2025 Demi Marie Obenour <demiobenour@gmail.com>
>> 
>> You add a copyright line here, but not in subsequent patches.  Is that
>> on purpose?
>
> No.
>
>>>  s6-ipcserver -1a 0700 -C 1 -b 1 env/crosvm.sock
>>>  
>>> -crosvm --no-syslog device gpu
>>> +bwrap
>>> +  --unshare-all
>>> +  --unshare-user
>> 
>> --unshare-all doesn't imply --unshare-user?
>
> It implies --unshare-user-try, but I want it to fail if it can't
> create a user namespace.

Aha!  Makes sense.

>>> +  --bind /run/user/0/wayland-1 /run/user/0/wayland-1
>>> +  --ro-bind /usr /usr
>>> +  --ro-bind /lib /lib
>>> +  --tmpfs /tmp
>>> +  --dev /dev
>>> +  --tmpfs /dev/shm
>>> +  --ro-bind /nix /nix
>>> +  --disable-userns
>>> +  --proc /proc
>>> +  --remount-ro /proc
>>> +  --ro-bind /dev/null /proc/timer_list
>>> +  --tmpfs /proc/scsi
>>> +  --remount-ro /proc/scsi
>>> +  --ro-bind /dev/null /proc/kcore
>>> +  --ro-bind /dev/null /proc/sysrq-trigger
>>> +  --tmpfs /proc/acpi
>>> +  --remount-ro /proc/acpi
>>> +  --
>>> +  crosvm --no-syslog device gpu
>> 
>> No indent necessary here.  This is a chain-loading program like many
>> others we use in execline scripts.  We don't indent for those or the
>> rightwards drift would be ridiculous!
>
> Should I indent the parameters above it?

Yeah I think that helps keep make it clear which exec they're scoped to.