Spectrum will, for now, be a Linux-based system, derived from NixOS. This gives us an actively-developed base with good hardware support, powerful and optimised compartmentalization primitives in KVM, and the reproducible packaging and configuration system that is important for a maintainable compartmentalized system.
The current plan is to implement compartmentalization in Spectrum by running each application inside crosvm, the hypervisor used by ChromiumOS. Qubes-style isolated, composited windowing for applications can hopefully be provided through its virtio_wl, which transports Wayland over the virtio protocol. Using a full virtual machine for each application might come with high resource requirements at first, but over time we should be able to optimise this, for example by doing clever tricks like DAX to a read-only storage device shared by multiple guests to save on duplicated memory. In the short term, it might be prudent to allow multiple applications to run in a single KVM instance, but our long-term focus should be on one per application instance.
Each virtual machine will be generated by
a Nix derivation. System and
user files within a VM will be shared, to reduce overhead and allow
the same files to be worked on from multiple VMs. An isolated VM will
read a directory tree from its on-disk representation, and expose it
to other VMs over a protocol chosen for simplicity to reduce attack
surface. The server inside this VM will be written in a memory-safe
language, to mitigate potential memory unsafety exploits. Ideally,
this server program would not rely on Unix filesystem code, but would
implement its own simplified file system logic, to interact with and
expose a file system as a directed acyclic graph, preventing the
possibility of a
directory
traversal attack. In simpler terms, this means that there should
be no concept of .. anywhere inside the filesystem VM in
relation to the exposed data.
There may be other writable mount points inside the virtual machine, but these will not persist between reboots of the VM. Using Nix to generate virtual machines allows them to be reproducibly built, rolled back, edited, and migrated as source code, rather than large, opaque virtual machine images.
This is a different model of data storage than has been used in previous implementations of security through compartmentalization. In Qubes, user data in each VM is stored in its own virtual block device. This works fine when multiple applications run in a single virtual machine, but would be unmanageable in Spectrum's VM-per-application model. As long as the appropriate precautions are taken, as described above, Spectrum's persistent model should be secure, while providing a more familiar and easier to understand model for users used to a single directory tree.
Which files and directories a VM should be able to access will be defined in Nix. Other resources and permissions, such as network cards and USB controllers, will similarly be defined in Nix. There are three logical sections for the Nix configuration -- applications, which are just packages, resources (virtual or physical devices, files and directories), and application instances, which are mappings between applications and accessible resources. This structure allows users to have multiple instances of the same application, with different permissions. It should be possible to grant additional permissions on a temporary basis at runtime, either through Spectrum system management UI, or through integrations into emerging standards for compartmentalized desktop computing like XDG Desktop Portals, which allow applications to ask for additional privileges through a standard interface, which must be confirmed by trusted user input before being granted.
Initial versions of Spectrum will have the user be responsible for writing Nix code for each application and resource, and the combinations they make between them. In future, it would be good if this could be handled by a graphical interface and a data file for simple cases, with Nix importing the data file and using it as input for the standard functions that would be called in a Nix-language configuration file. This use case should be kept in mind when writing the Nix API for Spectrum.
While Spectrum is expected to largely run on personal computers, most of which will almost certainly use the x86_64 architecture, this will not be the only architecture given first class support by Spectrum. One of the advantages to Spectrum's Linux base is the extremely wide hardware support that Linux offers, and, beyond that, x86_64 is notably untrustworthy, especially with the huge attack surface of the Intel Management Engine / AMD Platform Security Processor.
So, Spectrum will additionally have first class support for at least ppc64le. This architecture has been chosen because it is the only other architecture that can come close to the sheer performance x86_64 can offer at the high end, and because, in stark contrast to x86_64, it is possible to buy a new ppc64le (POWER9) system that does not require any proprietary firmware that cannot be inspected and audited. It is a goal of the project to build all packages, x86_64 and ppc64le, on POWER9 hardware. Even if a user has to trust the x86_64 computer available to them, anti-freedom firmware, undocumented backdoors and all, it would be a disservice to them to force them to use packages built on other such untrustworthy hardware.
You may distribute this content under the terms of either the CC-BY-SA license (version 4.0 or later), or the GNU Free Documentation License (version 1.2 or later), at your option.