Hacker News Reader

Comment by fsflover | Hacker News Reader

If you care about security, why not consider Qubes OS? Related discussion: https://forum.qubes-os.org/t/qubesos-vs-openbsd-security/790...

View on HN

If you really really care about security, then consider CHERI and CheriBSD

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Capability approach is just not practical and relies too much on security through correctness, which is unrealistic.

I was looking at that thread and honest question: how does Qubes OS deal with the binary blob issue? I would guess it is deblobbed to a certain extend according to [0]

But I couldn't find if they have a strict "no binary blob allowed" policy like OpenBSD.

- [0] https://doc.qubes-os.org/en/r4.3/user/troubleshooting/pci-tr...

They do not have a strict "no binary blob allowed" policy. Concerning VMs, they have a policy of minimal modifications: https://doc.qubes-os.org/en/latest/introduction/faq.html#wha...

The dom0 is based on Fedora and has the Fedora's policy for firmware blobs. See also: https://doc.qubes-os.org/en/latest/introduction/faq.html#wil...

Qubes OS uses the Linux kernel. Without wanting to start a flame-war and with all respect to Linux, it’s not even close. See: https://en.wikipedia.org/wiki/OpenBSD_security_features

https://isopenbsdsecu.re/

(This site is extremely good and has fairly recent coverage, point-by-point, of all OpenBSD's mitigations. An important subtext to take to this is that OpenBSD has a reputation for introducing mitigations that exploit developers make fun of. Some of them are great, some of them less so.)

The slides are over 6 years old. The developers' attitudes haven't changed much, but are all of the arguments still valid?

I've followed this discussion here and there over the years and it always goes like this:

1) everyone makes fun of the mitigations

2) many even outright assert they can easily defeat and exploit OpenBSD

3) nobody provides a working PoC when asked to demonstrate how insecure the OS is

And somewhere in the mix there's also you and your usual blabber, also without any substantial examples of how insecure and exploitable the OS is. Always.

The site isn't the slide deck. Let's talk after you've read it?

I have now read all of the points in the mitigations section. Just like the slides, the commentaries to the mitigations willingly assert uselessness and imply a sense of absolute insecurity, but without specific or even general examples.

So I'm looking forward to your careful explanation of how insecure the whole thing is and how easily it can be dismantled. Because I really want and need to know. Let's talk.

Wait, what? No they don't. The author is an OpenBSD person and calls out several mitigations as clever and worthwhile.

No, the author isn't an "OpenBSD person".

Isn't this Joshua Stein? (I feel like I've gotten this wrong before.)

No, AFAIK the author is German and his nickname is stein (stone).

It's not, and you have.

Rats! Some day I'll remember this. (I am a fan both of JCS and of the author of this page).

The “kernel” in Qubes is arguably Xen rather than Linux, and that’s where the security boundaries are supposed to be defined rather than within VMs that may be running any OS. VM compartmentalization as a security mechanism is hard to compare to a more conventional Unix like OpenBSD.

It's not just Xen, it also relies on the hardware-assisted virtualization (VT-d), which is virtually unbreakable compared to anything else. Most Xen vulnerabilities do not even affect Qubes: https://www.qubes-os.org/security/xsa/#statistics

You misunderstand the Qubes' approach to security. You isolate your workflows into separate VMs, so that security of a single VM doesn't matter. For example, my secrets are stored in a dedicated offline VM. All kernel bugs in it are just not exploitable. I open my online banking in a dedicated VM, in which nothing else is ever opened. Which attack vector do you think can be used against that?

Reply on news.ycombinator.com