Systemd inclusion in QubesOS

Does the use of systemd completely compromise the security of QubesOS?

No, it doesn’t. See this discussion:

1 Like

Is there a Devuan template available?

Not yet, but Qubes provides security through compartmentalization, and systemd can’t do much against that, except if it’s really malicious in dom0. For example, your offline VMs will never access the Internet and your compromised VMs will not access the data in the former.

“except if it’s really malicious in dom0”. Can you elaborate on this? It is a bit unclear.

I mean, dom0 has full access to your whole system. It can do anything and any software running in it should be trusted to not actively compromise your security. Unintentional bugs however are typically safe, since there is no_networking in dom0.

Can you please explain what is “unintentional bugs”? Could dom0 come installed with a maliciously modified version of systemd which has been compromised as part of a supply chain attack?

It’s in my links above (which I had to update, since I found more relevant doc pages):

Since there is no networking in dom0, any bugs discovered in dom0 desktop components (e.g., the window manager) are unlikely to pose a problem for Qubes, since none of the third-party software running in dom0 is accessible from VMs or the network in any way. Nonetheless, since software running in dom0 can potentially exercise full control over the system, it is important to install only trusted software in dom0.

1 Like

“Nonetheless, since software running in dom0 can potentially exercise full control over the system, it is important to install only trusted software in dom0”

Can you define what means “full control” over the system? What does “full control” mean?

Systemd is the very first process that runs. Can you tell me documentation that describes how systemd is integrated with Xen/QubesOS APIs?

“Full control” means that from dom0 command line, you can download, install and run any software in dom0 or in any VM: one, two.

Dom0 runs Fedora 32/37 with systemd. Dom0 is a VM with full privileges in the system. See also this post and posts below it: How does Qubes OS work? - #30 by fsflover.

That is a very large attack surface, look at all of the privileged functions available to dom0:

https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/

https://dev.qubes-os.org/projects/core-admin/en/latest/manpages/

That’s not to mention the RPC calls that can be made using qubesd, qubesOS store

qubes-create
qubesd-query

→ These functions allow for RPC calls between VMs

Have there been any fuzzing or security audits of dom0 command line tools?

  • core-admin
  • core-admin-client

However, nobody can attack it, except trusted software already running in dom0, which is minimized and verified. Even more compartmentalization is planned for future Qubes versions: GUI domain | Qubes OS.

You don’t have to use the core-admin. If you expect that it might have bugs, you simply switch off any inter-VM interactions (or interactions between trusted VMs).

But what if systemd is somehow interacting with this API because it is malicious from the beginning (i.e. a supply chain attack)?

How to disable core-admin API? How to switch off inter-VM interactions?

What does the GUI domain offer?

Does Qubes R4.1 already come with GUI-VM separation from dom0?

It’s discussed in my links above. You should continue these discussions, in order to keep this forum readable, if you’re interested.

You must trust everything running in dom0 in order to be able to run Qubes. You can verify and compile the code yourself, or rely on the Community for that. Also, the developers provide a possibility to verify that the code comes from them without any modification on the way.

It’s disabled by default: Admin API | Qubes OS

GPU and window manager will not have full access to dom0 anymore. Also there is audio domain to isolate the Pulseaudio and sound hardware (and Bluetooth).

Yes, but it’s in beta and without a strong hardware virtualization yet.

Strong hadware virtualization; can you elaborate on this? Do you mean iGPU or discrete GPU virtualization?

How long has it been in Beta?

Is GUI-VM virtualization stable? Can it be implemented using a saltstack formula in dom0?

there is a tutorial on how to enable the GUI-VM here:

I’ve never tried it not sure if it’s stable.

1 Like

Since the release of Qubes 4.1.

1 Like