Should systemd be removed from dom0 and isolated into its own VM? This is similar to how sys-gui
is isolated in its own VM due to the potential attack surface of graphics/window libraries.
Isolate the init system? Really? and start up how exactly? Or do you really mean REPLACE not isolate.
This sounds more like an old hate on systemd type post, I thought we were over that, what, go back to an older init system? Really bad idea, systemd is light years better now, sure it has issues here and there, and networkd is still crap, but going backwards isn’t a solution.
Just checked, you brought this up a few weeks ago (here) here we go again.
How else to mitigate the attack surface? Use app armour profiles? If they insist on using systemd, can they at least try and mitigate the vulnerable and buggy nature of systemd? Using app armour?
If they insist on using systemd instead of runit, or sysvinit; could we at least try to mitigate the bugs and the attack surface? I mean how can QubesOS call itself secure when there is so much evidence suggesting it is vulnerable and buggy?
They do not insist on that. As I said above, dom0 will likely be changed, see also this Issue:
Concerning how systemd currently affects the security of Qubes, please continue this discussion:
Systemd may very well be buggy, but those bugs are not exploitable, because you run nothing in dom0 (or suggest a way to exploit a bug in that discussion). Or do you have evidence that it’s malicious?
Yes. I keep getting a systemd related crash. It crashes the entire hypervisor somehow. It seems to
be more related to Whonix, but I can’t figure out how an RDRAND call could crash the entire hypervisor.
I supposed its not systemd per se, but RDRAND which is the real root of the issue. Would it then be advisable to follow the following hardening guide for the Xen kernel?