1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<link rel="stylesheet" href="style.css">
<title>Spectrum Design</title>
<body>
<nav>
<a href="..">Spectrum</a>
</nav>
<h1>Spectrum Design</h1>
<p>
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 <a href="motivation.html">important</a> for a maintainable
compartmentalized system.
<p>
The current plan is to implement compartmentalization in Spectrum by
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_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. 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
<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>
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
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.
<p>
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 <a href="https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf">notably
untrustworthy</a>, especially with
the <a href="https://invidio.us/watch?v=_eSAF_qT_FY">huge attack
surface</a> of
the <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine">Intel
Management Engine</a>
/ <a href="https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor">AMD
Platform Security Processor</a>.
<p>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.
<p>
<small>You may distribute this content under the terms of either
the <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC-BY-SA</a>
license (version 4.0 or later), or
the <a href="https://www.gnu.org/licenses/gfdl.html">GNU Free
Documentation License</a> (version 1.2 or later), at your
option.</small>
|