QubesOS vs OpenBSD Security

General Discussion
1

I was trying to decide what operating system I should use for as much acquirable security (while being reasonably usable and not living in the forest) as a daily driver.
I know since I’m posting this in the Qubes forum there may be bias towards Qubes, but I wanted to get some opinions on this topic, because I am very interested in learning more about this!

I know QubesOS calls itself a “reasonably secure” operating system, and the virtualization and compartmentalization of Qubes + the Linux OSes it uses do provide that. (I get into Qubes’ security after this)
However, OpenBSD claims to be the most secure system and it has a lot to help back up those claims. OpenBSD is a monolithic kernel (unlike Qubes), but OpenBSD has extremely in depth code audits, security built into the OS (like Qubes), and more, see the OpenBSD security page on Wikipedia.

According to author Michael W. Lucas, OpenBSD “is widely regarded as the most secure operating system available anywhere, under any licensing terms.”

And the OpenBSD security info page:

Our aspiration is to be NUMBER ONE in the industry for security

And finally, their motto: “Only two remote holes in the default install, in a heck of a long time!” But OpenBSD does have criticisms: (see the Wikipedia page above, section “Criticisms”)

Two years later, in 2019, a talk named “A systematic evaluation of OpenBSD’s mitigations” was given at the CCC, arguing that while OpenBSD has some effective mitigations, a significant part of them are “useless at best and based on pure luck and superstition”, arguing for a more rational approach when it comes to designing them.

Plus, some more criticisms (take it with a grain of salt seeing this is some random wordpress site that I found while DuckDuckGo’ing) here, but it does mention concepts like AppArmor, SELinux, and grsecurity. (but this was also written in 2010)

On the other side, QubesOS has Edward Snowden himself promoting and saying that Qubes is the most secure OS available today. On the Qubes website, Qubes shows the security of isolation via Xen and how you can run multiple OSes securely.

In terms of security, here’s what I’ve extrapolated:
-Maybe QubesOS can be compromised easier because it uses multiple operating systems (larger attack surface to send bugs that would theoretically exploit Xen bugs)
-OpenBSD is monolithic, but it uses something called “jails” instead of VMs. Maybe this is less secure?
-Qubes uses disposable VMs, so maybe it may have an advantage in erasing malware off of its system?
-Qubes has Whonix for even more DispVM / AppVM security: Whonix focuses on anonymity via Tor, but the Whonix devs also put a lot of time into security, see the Whonix docs. Some examples of this are all the kernel hardening implemented, along with Whonix being a hardened Debian variant (Kicksecure) if I remember correctly.
So I think the comparison here to make is either between the security of Qubes-Whonix ONLY and Qubes with all the default VMs being utilized as intended against the security of OpenBSD.

I know these are very different systems, but any advice would be welcome as to what to choose between Qubes and OpenBSD.

(Sorry I didn’t source everything, I originally had hyperlinks for most of these claims, but apparently I can’t post more than two links in a new topic for new users, but most of this stuff is just a search away)

1 Like
2

It’s not an either / or proposition. You can use Qubes OS to gain the advantages of compartmentalization and then run Whonix/Kicksecure/OpenBSD/whatever in those qubes.

Think of Qubes OS as a meta-OS. It allows you to have many virtual machines, isolated from each other, yet with well defined and very secure mechanism to share the same desktop, exchange files and clipboard contents securely.

It also isolates your hardware. Let’s say your OS and browser of choice have vulnerabilities that allow a remote attacker to access your microphone and webcam … well they are out of luck unless you have temporarily and knowingly assigned those hardware interfaces to a specific qube for a specific reason.

OpenBSD is best in security? I don’t know, but let’s assume it’s true. Wouldn’t it benefit to run in a template based qube with it’s root file system reset to a know state on every start? Wouldn’t it still benefit from being made disposable in certain circumstances (like viewing a suspicious file)?

It might sound over-the-top unless you are very familiar with Qubes OS… but it really is a way of computing more than an OS. It’s like an extension to make your computer way more safe and reliable REGARDLESS of which OSes you run inside the qubes. Yes, even Windows.

You can build virtual networking labs, try out new OSes, open suspicious files in disposables, have your qubes connect through VPNs, Tor or other networks without them ever having even a chance to escape that. Create/Backup/Restore virtual machines (“qubes”) within minutes.

Running any OS on bare metal and connecting it to the internet instead of in a qube just seems irresponsible to me at this point.

5 Likes
3

Qubes’ security relies on compartmentalization. By compromising any single VM, you do not compromise the security of Qubes. In fact, Qubes expects that your VMs can be compromised, and does not allow them to interoperate (by default).

How does Xen result in a larger attack surface? Have a look at how Xen exploits affect Qubes: Xen security advisory (XSA) tracker | Qubes OS. Find among them those which allow escaping VT-d hardware virtualization (AFAIK you won’t).

The security-critical code in Qubes has much lower number of lines of code than that for OpenBSD. To me it means that the attack surface of OpenBSD is larger.

1 Like
4

Indeed, let’s assume it’s true. Now, compare two hypothetical use cases: 1) you run OpenBSD on the bare metal and 2) you run the same OpenBSD as a Qubes VM.

In the second case, if your VM is compromised, it does not mean that the other VMs, or dom0 are compromised, too. For that, you would need to additionally escape the virtualization. Now, take into account that you do not run everything in this single VM. First, it’s not directly connected to the network (no drivers/firmware). In Qubes you are expected to separate your workflows, i.e., use a separate VM for visiting random websites (probably a disposable VM), separate for storing passwords (without any access to the Internet), another one for accessing your email. Each of those VMs has a much smaller attack surface, simply because it does less. Isn’t it more secure than the first case?

1 Like
5

Why not both? @unman uses OpenBSD as his sys-net, since sys-net can be considered one of the weakest links in a Qubes system.

Someday I’ll figure out how to use OpenBSD VMs without setting my computer, my house, and/or myself on fire----someday.

P.S. Also, I remember there was talk somewhere about a Qubes-like system built around OpenBSD called something French like Bastille.

2 Likes
6

Thank you for the responses! I’m leaning towards using Qubes-OpenBSD, but the last concern I have is with attack surface:

You can use Qubes OS to gain the advantages of compartmentalization and then run Whonix/Kicksecure/OpenBSD/whatever in those qubes.

The issue I see with that is that using Qubes and OpenBSD will have a larger attack surface than if I just used OpenBSD. If I did use Qubes, I’ll follow the advice given and switch sys-net to OpenBSD (thanks for that link), but if an attacker will want to attack the setup, he’ll just try to find an OpenBSD bug, or a Xen breakout bug. Let’s assume both of those are of equal difficulty to find.
If an attacker gets access (meaning it isn’t compromised, but malicious code is running, such as JS) to a VM, could he theoretically just directly attack the hypervisor instead of working on getting any more data / permissions from OpenBSD? If this is true, a Qubes-OpenBSD setup will be less secure than a purely OpenBSD setup right? If an attacker has to compromise the entire VM to break out, and THEN break Xen virtualization, then Qubes-OpenBSD is clearly superior to OpenBSD on bare metal. But maybe all of this depends on the kind of exploit?

In the second case, if your VM is compromised, it does not mean that the other VMs, or dom0 are compromised, too. For that, you would need to additionally escape the virtualization.

Just directly responding to this too: what if the attacker just directly targets the virtualization instead of the OS?

7

I am not sure I get your logic.

a) an attacker compromises an OpenBSD install, gets code execution and exfiltrates all your data

b) an attacker compromises an OpenBSD qube, gets code execution, performs a virtualization escape, moves laterally to exfiltrate data from other qubes

The keyword here is “virtualization escape”. So you are worried that someone could find and exploit a virtualization escape FROM JavaScript running in a browser instance in an OpenBSD qube. Can I prove this is impossible? No. Is it reasonable?

8

It sounds like you are assuming that “more software” = “larger attack surface.” But that’s not how it works. What matters is how large your TCB is.

The TCB of Qubes OS is extremely small. Running OpenBSD in a qube would not increase the TCB of Qubes. It would simply make that qube harder to exploit (assuming OpenBSD is harder to exploit than alternative OSes you would run in that qube).

In that case, the attacker would have to find two difficult (and unrelated) vulnerabilities instead of just one in order to compromise your whole system. By contrast, if you were simply running OpenBSD on bare metal, the attacker would only have to find one difficult vulnerability to compromise your whole system.

It depends on a lot of factors, including the OpenBSD security features in that qube, but it’s possible.

No, that doesn’t follow logically. In the setup you just described, the attacker performs a Xen hypervisor escape from an OpenBSD qube without compromising the OpenBSD qube, so the attacker has compromised one thing in order to (let’s assume) compromise the whole system. If it were a bare metal OpenBSD installation, the attacker would still have to compromise one thing (a different thing – OpenBSD instead of Xen) in order to compromise the whole system. If you’re stipulating, for the purpose of this thought experiment, that they’re both equally difficult to compromise, then Qubes+OpenBSD is, at worst, no less secure than plain OpenBSD and, at best, more secure.

(Note that this is a highly theoretical discussion that abstracts away from the technical properties of Xen and OpenBSD to an extreme degree. We’re mainly focusing here on the logic of the argument rather than the reality of the software.)

3 Likes
9

I’ve been thinking about a similar question recently. iirc OpenBSD dropped jail support some time ago. They also dropped linux emulation quite a while ago as well. I like OpenBSD and I’m thinking of using it for some packet filtering. For a desktop though, I’m not so keen on it.

Using OpenBSD as a desktop system would require installing several hundred third party packages. Many (most?) of them will be the same packages that would get installed on a Linux system, just compiled for *bsd. These packages do not undergo the same level of scrutiny that the base OpenBSD system gets.

Take it w/ a grain of salt as I’m by no means a security expert, very far from it, however the exploitable bits on a system seem to start at the browser and related libs would they not? Kind of suspect that the bits that are exposed to attack are similar on either os. Just that once an exploit on the browser is found, where do they go from there and what does that get them and how high is the technical proficiency required to pull it off.

Personally I’m kind of leaning towards Linux w/ falco and a wazuh agent and am contemplating FreeBSD and jails as well w/ a wazuh agent running. One thing about Qubes that I wonder about is the difficulty (or ability?) to run some kind of file integrity checker.

I don’t really have the time to spend on it but my ideal setup would include some kind of file integrity checker in dom0 and each vm plus having falco in dom0 and each vm. Linux vms of course. I’m a fan of FreeBSD desktops but not having something like falco is a bit of a drag there.

I like the idea of running openbsd as a net vm, gotta remember to look into that one.

10

According to the project’s site, “Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.” See https://bastillebsd.org/ for details.