How are syscalls handled in QubesOS by VMs compared with other OSes
(GrapheneOS) for example.
In QubesOS, all syscalls are handled by the Linux kernel running inside the same qube. This is great, because the Linux kernel is a huge attack surface, and vulnerabilities in syscall handling is very common, but since the Linux kernel is running in the same qube, this won’t compromise any other qube.
On GrapheneOS however, exploiting a vulnerability in syscall handling would compromise the whole system, including all running user profiles, as there is only a single Linux kernel running, and it has access to the whole system.
In this sense, QubesOS provides far better attack resistance than GrapheneOS. It is these specific kinds of attacks QubesOS is designed to protect against.
With that said, QubesOS is not immune to attacks, as there is still interfaces between qubes and the hypervisor. It is just, those are far smaller, and thus will have far fewer vulnerabilities found.
1 Like
what is most likely method of VM or dom0 compromise?
It will be X Window system? systemd?
It will be Fedora distro library dependency compromise? (supply chain)
In practice, I would guess probably downloading scripts/executables in a domU, then copying them to dom0 and running them is one of the most likely
It’s sometimes necessary for small scripts, I try to review anything I run in dom0, and don’t run anything too big to inspect manually. I’m sure some people are not as cautious, despite very clear documentation and warnings about the danger
how is dom0 compromise detected?
I think all the security vulnerabilities that have been the last few years have been CPU microcode vulnerabilities that allow reading and writing arbitrary memory across virtual machines, and Xen vulnerabilities that are similar in nature to that.
As far X window system, there isn’t that much attack surface really. Each virtual machine have a framebuffer they draw to, and the already rendered graphic is just copied out from there into a window. Other than that it is basically just setting window title, window size and current mouse cursor, all done through a QubesOS specific communication protocol. So the unprivileged qubes does not really have any means to interact with the X window system running in dom0 themselves, so risk of compromise is really low. They cannot interact with systemd in dom0 at all.
Vulnerabilities can hypothetically be found on the QubesOS specific protocols for communication with dom0. There is also quite some attack surface exposed between VMs that have network connectivity enabled (a net-vm assigned to them), but this does not include dom0.
In general, you can never detect a compromise. Unless of course your private data leaks and gets posted on internet, or your files and data gets destroyed, or some other visible consequence.
In general though, as long as you leave dom0 untouched, risk of compromise is extremely small.
1 Like
You should never run anything in dom0. I thought they had disabled clipboard sharing and file transfer to dom0 to discourage people from doing that.
You can detect compromises using logs and checksums/hashes.
There was a plan to move the clipobard into a dedicated gui-VM and to isolate the X Window
system inside of it.
No, not as QubesOS is designed currently. If an attacker has compromised dom0, they have write access to all logs, and can conceal their presense. And dom0 is not protected in such a way verifying hashes are meaningful right now. There might be plans for making dom0 immutable and adding on dm-verity or similar in the future, which would allow for this.
can you explain why hash verification is not meaningful.
dm-verity sounds like a good idea.
Immutability would also help.
To verify the hashes in a secure way, you would need 1) perform the verification before booting QubesOS, so, either from a USB stick or using verified boot, and 2) need to already know the trusted hashes of all boot and dom0 files or the whole image. Remember, you cannot trust anything in dom0 when verifying, so cannot obtain the hashes from there or use its software to verify.
Theoretically you could boot from a USB stick, and calculate all hashes for all boot and dom0 files and save them on the USB stick, for a freshly installed and known not compromised QubesOS installation. And then just boot from the USB stick again every time you want to verify. But this is hard to do right, as dom0 modifies files during normal usage and especially during updates, so you would no longer have a trusted source for the hashes.
Verified boot + immutable image protected with dm-verity would allow for performing this verification in a safe way, and automatically at every boot.
verified boot using a TPM?
Any implementation of verified boot. My understanding is that QubesOS developers seem to be interested in using the SecureBoot functionality already present on most UEFI firmwares. Likely, the verified boot methods available in HEADS can also be used for this in such a future.
QubesOS does not at present verify the integrity of dom0 using Heads boot firmware.
The TPM is not used to store the hash.
True, verification of dom0 integrity is not implemented yet.
so there’s no real means of detecting a dom0 compromise.
CPU microcode compromises meaning what, the IntelME flashed to the SPI chip?
No, not Intel ME, but the microcode running on the CPU itself. Even the CPU needs firmware, that might have vulnerabilities. I haven’t kept up at all, but Spectre and Meltdown were two famous CPU microcode vulnerabilities.
1 Like
These have been patched? Or still vulnerable.
Patched, of course. Intel and AMD have patched all microcode vulnerabilities that have been discovered, for all still supported CPUs. QubesOS bundles the latest version of the microcode from Intel and AMD, and loads it during early boot.