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?