Does the use of systemd completely compromise the security of QubesOS?
No, it doesn’t. See this discussion:
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.
“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?
That is a very large attack surface, look at all of the privileged functions available to dom0:
That’s not to mention the RPC calls that can be made using qubesd, qubesOS store
→ These functions allow for RPC calls between VMs
Have there been any fuzzing or security audits of dom0 command line tools?
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.
Since the release of Qubes 4.1.