Hello
So I tried to look over what happens in my system, and then apply some
hardening to it. The following is what I got.
/////
Design sketch of a SpectrumOS prototype
User starts an application with some choice of VM base
image/capabilities, store paths available inside the VM, the store paths
to add to environment, state directories readable/writeable in VM,
external capabilities connected to the VM, internal devices visible to
the applications.
Single-use state directory may be designated to provide a VM with
fully-owned secondary-storage-backed tmp-like space.
Layout of the state directories visible to the VM can be adjusted.
As a special case support there is support for generating VM-specific
configuration files such as /etc/passwd (these should not be prebuilt
due to per-launch UID generation).
A unique UID is assigned to the VM. This UID is added to the ACLs so it
can read the state directories assigned and all their subdirectories
(files are world-readable by default). It also gets access to write to
the writeable directories and possibly to some of the files in these
directories
UIDs/ACLs are tracked. The user can assign a UID to an alias for further
reuse (this reduces the need for updating ACLs all the time). One-time
UIDs are reused as rarely as possible. When a VM with a single-use UID
quits, its UID is removed from the ACLs of the granted files. There is
also a periodic enumeration of files in order to clean up long-obsolete
ACLs in came of unclean shutdown or similar events.
A temporary directory is created. Everything that should be visible
inside the VM is bind-mounted there. This includes devices. An isolated
environment is set up for the VM to run.
VM is started serving the state directories and store paths to the
inside via virtfs/virtio-fs.
Inside VM the extra device node are removed from /dev/. Requested store
paths are added to PATH and possibly to other variables like
LD_LIBRARY_PATH or QT_PLUGIN_PATH as requested. Read-only state
directories are bind-mounted over themselves read-only. The specified
program is started normally under numerically the same UID as assigned
to the VM (to avoid the need to use UID mapping).
There are some predefined wrappers to launch a program requiring, for
example, a D-Bus session in a VM-local D-Bus session.
A special type of wrappers is restricted-environment setup, to reduce
the ability of an program to attack the surrounding VM.
(VM might eventually run a different OS kernel type than the host)
Special kinds of resources:
Expected to be handled by the VM: DRI passthrough. Sound passthrough
(wrapper to launch full isolated PulseAudio).
GUI is handled via virtio-wayland.
Local sockets (such as ssh-agent): hopefully can be handled by the file
sharing solution.
Network: VM connected by socket to a virtual switch leading to a
firewall VM, VM itself runs in no-network environment. Cross-VM network
links do not correspond to any visible files inside the VM-surrounding
isolated environment. A firewall VM per ruleset (can be shared for
multiple Firefox instances with the same security profile). Firewall VMs
connect via a virtual switch to the network-handling VM; it may have
addressless filtering bridge VMs on both sides.
External storage: considered a special case of state storage; might not
support ACLs (so access control is purely by ro/rw bind mounts outside
and inside the VM).
Nontrivial external hardware: USB/PCI pass through?
