mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-18 04:04:39 -05:00
109 lines
3.9 KiB
ReStructuredText
109 lines
3.9 KiB
ReStructuredText
======================
|
||
Security-critical code
|
||
======================
|
||
|
||
|
||
Below is a list of security-critical (i.e., trusted) code components in
|
||
Qubes OS. A successful attack against any of these components could
|
||
compromise the system’s security. This code can be thought of as the
|
||
Trusted Computing Base (TCB) of Qubes OS. One of the main goals of the
|
||
project is to keep the TCB to an absolute minimum. The size of the
|
||
current TCB is on the order of hundreds of thousands of lines of C code,
|
||
which is several orders of magnitude less than other OSes. (In Windows,
|
||
Linux, and Mac OSes, the amount of trusted code is typically on the
|
||
order of tens of *millions* of lines of C code.)
|
||
|
||
For more information, see :doc:`Qubes Security Goals </developer/system/security-design-goals>`.
|
||
|
||
Security-critical Qubes-specific Components
|
||
-------------------------------------------
|
||
|
||
|
||
The following code components are security-critical in Qubes OS:
|
||
|
||
- Dom0-side of the libvchan library
|
||
|
||
- Dom0-side of the GUI virtualization code (``qubes-guid``)
|
||
|
||
- Dom0-side of the sound virtualization code (``pacat-simple-vchan``)
|
||
|
||
- Dom0-side in qrexec-related code (``qrexec_daemon``)
|
||
|
||
- VM memory manager (``qmemman``) that runs in Dom0
|
||
|
||
- Select Qubes RPC servers that run in Dom0: ``qubes.ReceiveUpdates``
|
||
and ``qubes.SyncAppMenus``
|
||
|
||
- The ``qubes.Filecopy`` RPC server that runs in a VM (critical because
|
||
it could allow one VM to compromise another if the user allows a file
|
||
copy operation to be performed between them)
|
||
|
||
|
||
|
||
Security-critical Third-party Components
|
||
----------------------------------------
|
||
|
||
|
||
We did not create these components, but Qubes OS relies on them. At the
|
||
current stage of the project, we cannot afford to spend the time to
|
||
thoroughly review and audit them, so we more or less “blindly” trust
|
||
that they are secure.
|
||
|
||
- The Xen hypervisor
|
||
|
||
- Xen’s xenstore backend running in Dom0
|
||
|
||
- Xen’s block backend running in Dom0’s kernel
|
||
|
||
- The RPM program used in Dom0 for verifying signatures on dom0 updates
|
||
|
||
- Somewhat trusted: log viewing software in dom0 that parses
|
||
VM-influenced logs
|
||
|
||
|
||
|
||
Attacks on Networking Components
|
||
--------------------------------
|
||
|
||
|
||
Here are two examples of networking components that an adversary might
|
||
seek to attack (or in which to exploit a vulnerability as part of an
|
||
attack):
|
||
|
||
- Xen network PV frontends
|
||
|
||
- VMs’ core networking stacks (core TCP/IP code)
|
||
|
||
|
||
|
||
Hypothetically, an adversary could compromise a NetVM, ``sys-net-1``,
|
||
and try to use it to attack the VMs connected to that NetVM. However,
|
||
Qubes allows for the existence of more than one NetVM, so the adversary
|
||
would not be able to use ``sys-net-1`` in order to attack VMs connected
|
||
to a *different* NetVM, ``sys-net-2`` without also compromising
|
||
``sys-net-2``. In addition, the adversary would not be able to use
|
||
``sys-net-1`` (or, for that matter, ``sys-net-2``) to attack VMs that
|
||
have networking disabled (i.e., VMs that are not connected to any
|
||
NetVM).
|
||
|
||
Buggy Code vs. Backdoored Code
|
||
------------------------------
|
||
|
||
|
||
There is an important distinction between buggy code and maliciously
|
||
backdoored code. We could have the most secure architecture and the most
|
||
bulletproof TCB that perfectly isolates all domains from each other, but
|
||
it would all be pretty useless if all the code we ran inside our domains
|
||
(e.g. the code in our email clients, word processors, and web browsers)
|
||
were backdoored. In that case, only network-isolated domains would be
|
||
somewhat trustworthy.
|
||
|
||
This means that we must trust at least some of the vendors that supply
|
||
the code we run inside our domains. (We don’t have to trust *all* of
|
||
them, but we at least have to trust the few that provide the apps we use
|
||
in the most critical domains.) In practice, we trust the software
|
||
provided by the `Fedora Project <https://getfedora.org/>`__. This
|
||
software is signed by Fedora distribution keys, so it is also critical
|
||
that the tools used in domains for software updates (``dnf`` and
|
||
``rpm``) are trustworthy.
|