Hacker News Reader

Comment by fsflover | Hacker News Reader

> Dom0 (the admin Qube) is running the Linux kernel and is vulnerable

Yes, it is vulnerable, except there is no attack vector, as you don't run any software there: https://doc.qubes-os.org/en/r4.3/user/downloading-installing...

> DomU (App Qubes) also run the Linux kernel and are just as vulnerable.

I think you misinterpret the Qubes approach to security. If you do everything in one VM, you get no protection from the virtualization. Moreover, there is no sudo password by design: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-s... This is not how to use Qubes.

You need to compartmentalize your workflows. It doesn't matter if my disposable VM is compromised. My secrets are in another, offline VM, where I never run anything. There is no way to use the discussed vulnerability, if one uses Qubes according to docs. See examples here: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to...

View on HN

So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.

> https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...

Looking at just that small list, they mark some vulnerabilities as not vulnerable because it's "In-VM attack only". That's disingenuous.

> There is no way to use the discussed vulnerability, if one uses Qubes according to docs

It's like saying you're not vulnerable to cutting yourself with a knife, as long as you use it correctly.

You can say your risk is low, but you can't say you're not vulnerable.

---

> Moreover, there is no sudo password by design

The POC uses `/usr/bin/su`, but that's besides the point.

The vulnerability itself can affect other things. The POC just used root-privilege escalation as an example.

https://access.redhat.com/security/cve/cve-2026-31431

RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.

> So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.

On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash".

> "In-VM attack only". That's disingenuous.

It's really not. Hardening of guest OSes is out of scope of Qubes. You are supposed to not combine trusted and untrusted actions in a single VM, so intra-VM security is really secondary. I really recommend you to read my link about organizing the workflows.

You have a good point concerning the integrity issues though.

> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.

And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.

To be completely fair, any kind of sandboxing inside of Qubes's VMs do not mean much, because it is on X11. Any app can pwn any other app lol.

With that being said, yeah, he's being disingenuous as per usual for sure. Part of Qubes hardening is trying to not allowing an attacker to gain root to make it harder to attack Xen, but our evangelist here claims it doesn't matter if an attacker has root :)

Reply on news.ycombinator.com