The importance of compartmentalization

I know I’m preaching to the choir, but this should be a delight for Qubes’ supporters to read:

From the top comment of Hacker News’ discussion of “SolarWinds hack was ‘largest and most sophisticated attack’ ever: MSFT president

I’ve found my experience designing gearboxes for Boeing has applicability to software design. For example, the fundamental idea with airplane design is not to design components that cannot fail, as that is impossible. The idea is to design the system to be tolerant of failure . Every part in the system is not “how can we make this part never fail” but “assume it failed. How does the airplane survive?”

This is a fundamental shift in viewpoint.

It seems pretty well established that making secure software is impossible. Time to pivot to designing software systems that are tolerant of inevitable security breaches.

One example of this is compartmentalization. A single breach must not have access to all the sensitive data. Another is backups must be air gapped (or put on physically read-only media) so ransomware cannot compromise them.

Compartmentalization is used in battleship design, aircraft design, spy networks, etc. Time to use it in software systems design.

P.S. Just to be clear, one still strives to design airplane parts so they won’t fail, it’s just that one does not rely on them never failing.

P.P.S. It’s really really hard to sink a battleship as they are so compartmentalized. See the sinking of the Bismarck and the Yamato.

Still no mention of Qubes in that thread, yet.


Further thoughts: To be fair, Qubes does have a critical point of failure–if the Xen that underwrites everything gets compromised, it’s Game Over™. IMO from the VMs’ perspective it’s not too different from having the laws of physics compromised.

Is there a way to compartmentalize Xen itself so that attempts to compromise the virtualizer via VM doesn’t allow the attacker access to anything else? I feel like I’ve read something about this before; maybe it’s already been implemented.

P.S. The author also makes an irresistible case for renaming Qubes OS to Bismarck OS or Yamato OS.

Here’s a neat picture showing just how compartmentalized battleship Yamato was:

1 Like

Qubes does have a critical point of failure–if the Xen that
underwrites everything gets compromised, it’s Game Over™.

That’s why “reasonable” security. And beyond Xen you have the entire
domain of hardware to worry about, which is the far bigger issue from my
point of view:


Let me remind you that Titanic was compartmentalized as well :slight_smile:


You know, it might actually be a good idea to name this Titanic OS (there’ll definitely be malware targeting this codenamed ‘Iceberg’)–it’ll remind people that this is not an infallible system and will prevent overconfidence. I mean, the same could be said for Yamato and Bismarck, both thought to be unsinkable, but the Titanic is more well known.

Firmware and hardware are always on my mind, but they’re both things I can’t do much about other than not buying second hand laptops and brands I don’t trust (e.g. Lenovo) and updating BIOSes with carefully verified updates.

Out of curiousity, do practicing infosec professionals manage hardware to the extent they verify hardware and firmware? I doubt it happens in all but the largest companies.

1 Like

Since you made your research, would you mind naming brands which you trust and which provide verifiable BIOS updates?

1 Like

This prompts a separate thread in the #all-around-qubes category, I think.

1 Like

Related, but maybe not so much, would a reproducible build or checksum checking have mitigated the software supply chain hack? If yes are there any efforts to achieve this in Xen?

1 Like

I think we may have different definitions of ‘verify’ here. What I meant was I make sure to carefully check the shasums, while you probably mean going through the source code of the update.

AFAIK most vendors provide the former, while very few provide the latter.

(This ends the short digression, but I think both vendor trust and BIOS or boot security are interesting topics for the new place)

1 Like

Would be a good question for this discussion:

Since you show the interest, I created a thread for that: .

1 Like

Please find my reply here:

1 Like

@fiftyfourthparallel There seem to be some attempts to decompose Xen and thus provide compartmentalization within the hypervisor:

I don’t know, however, how far these projects have gonw in the last years, and what they have achieved.

An other possibility might be to replace Xen with a verified microkernel, like L4, as I proposed some time ago in Qubes issue #3894. It should be possible, but would probably require a lot of work - and resources to do it!


An L4 seems far off, optimistically speaking.

The Xen compartmentalization papers are way beyond me (thanks for linking them though). It might as well be written in Swahili. Hopefully the Xen team is looking into it, since a compromised Xen means a compromised Qubes OS.

Is Xen a valuable target to penetrate and is it challenging to do so assuming you have root on a VM it’s hosting (say, a Linux VM)? I know XSAs are frequent and there have been a few critical ones, but my impression is that despite being a valuable target there have been few (none?) in-the-wild attacks–that we know of.

1 Like

When i try this link I am told its private or closed?

When i try this link I am told its private or closed?

Hi stumpi, the respective post is in the “All around Qubes” category
which we are currently only showing for members who have been around a
few weeks and actively participated (aka trust level 2).

The reason is that the entire category was created to allow discussions
that would otherwise be off-topic to this forum but that are still of
general interest to people who use Qubes OS.

You should reach level 2 shortly and then you will be able to see this
post too. Sorry for the confusing message. It was really my mistake to
post this here in that form.

1 Like

Given the context (SolarWinds hack) and after reading the HackerNews thread, a secondary point should be emphasized: intrusion detection. This is something that is not currently available by default in Qubes OS (to my knowledge), which is unfortunate, but it is something that is worth consideration and implementation. Compartmentalization helps limit attacker access and attack scope, while intrusion detection helps inform the victim of attacker access and attack scope; they are complementary and reinforce the security of each other.

Given enough time and resources, any limited access can eventually be expanded by penetrating deeper into the system through its vulnerabilities; if this is never detected, compartmentalization may never be sufficient against a determined and well-funded attacker. This is because security by isolation depends on security by correctness at some level: an incompetently coded and obviously broken compartmentalization scheme will not be very effective and may only provide a false sense of security.

(This is in part a critical application of ITL security modeling.)

Just some thoughts,

1 Like

To add to this: passwordless root should be disabled by default, replaced by something like a sudo prompt. Apparently even Joanna has reversed her previous position on it, yet in R4.1, passwordless root is default on all non-minimal templates.

We should be applying the Swiss cheese model of engineering by closing as many holes as possible, not opening a gaping hole in each simply because it’s convenient and because Qubes has more pieces of cheese. This sort of arrogance is what sunk the Titanic, Yamato, and Bismarck,