about summary refs log tree commit diff
diff options
context:
space:
mode:
authorAlyssa Ross <hi@alyssa.is>2019-12-23 00:38:38 +0000
committerAlyssa Ross <hi@alyssa.is>2019-12-23 00:39:56 +0000
commit7557138bad3f3284dba1bdf0f6e00305b4a63a33 (patch)
tree927d18e721f31cbe9d2d0fb739ac227dbe54338f
parentd3ad1952235f01e351ca3ecb52c45563ac849591 (diff)
downloadwww-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar
www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.gz
www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.bz2
www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.lz
www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.xz
www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.tar.zst
www-7557138bad3f3284dba1bdf0f6e00305b4a63a33.zip
design: expand on inter-VM communication
-rw-r--r--design.html91
1 files changed, 60 insertions, 31 deletions
diff --git a/design.html b/design.html
index b927bea..ca70c01 100644
--- a/design.html
+++ b/design.html
@@ -28,42 +28,71 @@ running each application
 inside <a href="https://chromium.googlesource.com/chromiumos/platform/crosvm/">crosvm</a>,
 the hypervisor used by ChromiumOS.  Qubes-style isolated, composited
 windowing for applications can hopefully be provided through its
-virtio-wayland feature, or failing that
-through <a href="https://xpra.org/">Xpra</a>.  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 <a href="https://lwn.net/Articles/610174/">DAX</a> 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.
+virtio_wl, which
+transports <a href="https://wayland.freedesktop.org/">Wayland</a> over
+the <a href="https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf"
+title="virtio: Towards a De-Facto Standard For Virtual I/O
+Devices">virtio</a> 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 <a href="https://lwn.net/Articles/610174/">DAX</a>
+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.
 
 <p>
 Each virtual machine will be generated by
-a <a href="https://nixos.org/nix/">Nix</a> derivation, and will have a
-completely immutable root file system.  Persistent storage will be
-provided by virtual block devices, that arbitrary paths on the system
-can be mapped to from the host.  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.
+a <a href="https://nixos.org/nix/">Nix</a> derivation.  System and
+user files within a VM will be shared, to reduce overhead.  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 
+<a href="https://en.wikipedia.org/wiki/Directory_traversal_attack">directory
+traversal attack</a>.  In simpler terms, this means that there should
+be no concept of <code>..</code> anywhere inside the filesystem VM in
+relation to the exposed data.
 
 <p>
-Virtual block devices will also be defined in Nix, and block devices
-and applications will be <var>m</var>:<var>n</var>.  Some virtual
-machines may have no persistent storage, or even write access to a
-disk, at all.  In other cases, it might be desirable for multiple
-applications to be able to access the same device, such as a local
-mail store being shared by two mail clients.  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), and <i>application instances</i>, which
-are mappings between applications and accessible resources.  This
-structure allows users to have multiple instances of the same
-application, with different permissions.
+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.
+
+<p>
+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.
+
+<p>
+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 <i>application instances</i>, 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 <a href="https://github.com/flatpak/xdg-desktop-portal">XDG
+Desktop Portals</a>, which allow applications to ask for additional
+privileges through a standard interface, which must be confirmed by
+trusted user input before being granted.
 
 <p>
 Initial versions of Spectrum will have the user be responsible for