Is it possible to remove Systemd and all of its sub-components from Qubes? Are these daemons
capable of opening network connections to/from a VM? Is there a way to check systemd network
connections?
Would this be primarily an issue within the dom0 OS? Which is now using Fedora. Is it possible to
replace this with Devuan?
Could a mirage unikernel (LibraryOS) potentially be used?
So many questions in a single thread.
Of course it is possible. Many parts of Qubes use systemd services so
you will have to rewrite these to remove that dependence.
I don’t know what this means. Do you mean identify any service that could open
a network connection?
How would you identify a sysvinit script that might open a network
connection?
Yes, it is possible.
Read this
1 Like
I don’t know what this means. Do you mean identify any service that could open
a network connection?
How would you identify a sysvinit script that might open a network
connection?
What I mean is, how can I check for network connections which might originate from a systemd service?
If I suspected there was a memory leak somewhere in my system and I wanted to investigate specifically systemd network services, how would I do this?
An exploit which had opened a network connection by way of a systemd process.
You can use sudo netstat -tupa it should give you the name and pid of processes with an active connection, or that are listening.
Did you find the answer by looking it up in the linux man pages?
Was it in an online resource?
For Systemd to have any network connection out of dom0 there would have to be a Xen network interface created for that connection, and with out of the box Qubes that simply does not exist.
Systemd might create a loop back interface within dom0 but systemd does not natively understand that it is even running under Xen, so why the worry unless you mistakenly loaded a 3 letter agency Trojan into your dom0.
If you did load a Trojan then the network connection could piggyback on top of the pipes used for communications with the AppVMs (simultaniously hacked) which could then act as a network proxy, but I doubt any of that would be done by systemd by default. If any of that is true then your system has already been compromised and systemd is the least of your worries.
I realize there are reasons that some people do not trust systemd but this paranoia seems to be overblown. The init system has its own set of problems and removing systemd is just trading one set of problems for another.
I would agree on a micro kernel would be a safer and more secure system for dom0. If you are going to spend time securing dom0 then an auditable and verifiable microkernal is a much better way to go.
1 Like
Is it even possible for a trojan to make its way into dom0? or would a system compromise more likely come from a corrupt networking driver?
What would be the most likely place for a trojan file to reside? within the dom0 Fedora template? Within the Xen hypervisor itself?
Is it possible to run an anti-virus on dom0(fedora)? or on Xen?
Anything that you copy to or install into dom0 is a potential pathway. Or if the update repository is somehow tainted but it still passes the signing of the updates then that could be a way in. Qubes attempts to prevent this but a rogue actor with the proper signing keys could get around these protections, theoretically. How they would target you personally and not everyone would be much more difficult. If a nation state actor has you in their sights then anything goes.
Stuxnet for example demonstrates how much effort it takes to target a specific system, yet because they accidentally infected other systems outside of their target network they were finally detected.
In any binary on dom0, which is why copying files into dom0 is widely frowned upon in the Qubes community. Don’t install software in dom0 unless you absolutely trust its pedigree.
To get to Xen you must already control dom0, but you need to break into dom0 by using Xen.
The attack surface from the network is either the network card in sys-net or a user level application in an AppVM. The DMA in the network card is confined to only the sys-net VM so you won’t be able to scribble over Xen or dom0 memory without a Xen exploit. You may have noticed the the Xen security announcements from time to time, and that is why the Qubes team takes those so seriously.
The AppVM applications may allow an adversary to get a foothold into one of your VMs by exercising a software vulnerability in your application. If they gain root privileges in your AppVM they are again stuck in that VM without a pathway into dom0. There is no networking in dom0 for exactly this reason.
This is unlikely to help much. All AV software can detect only things that it has seen before and built a pattern for each kind of malware found out in the wild. If your adversary is a nation state or three letter agency the the malware created for you specifically would be unique therefore there would be no known signature and would not be detected.
Many AV scanners use a ‘default allow’ rule rather a ‘default deny’. The safest method would be to deny execution on all binaries except those that have explicitly been permitted. There are software that can implement this on Linux but I have not tested this. After all what do you do when looking at a bash or python script? The script itself, not the executable interpreting it would be the problem.
1 Like
Would you say that something like a malicious Python script within the QubesOS repo is the most likely attack vector to exploit dom0?
If this is the case, how would dom0 go about exploiting all of the other VMs? Which API would the malicious script interact with to compromise the security of a VM?
How would malicious dom0 script go about exploiting the dom0 breach? Would this be using qrexec API? systemd API?
How would the malicious actor go about identifying a specific target in a supply chain attack like this? Is there some way of ID’ing a specific user?
Aren’t updates anonymized by requesting them over Whonix?
Is there a way for a user to compare the hash of a known good (not compromised) build version with their own build version?