How to minimize dom0?

How does the binary blob get activated?

Through the “innocent bug”.

But unless something happens in dom0 to activate it, where’s the hazard?

You asked about an example scenario and I answered. That scenario involves “something to happen”. Now you are asking to exclude essential parts of the scenario in order to prove that it is a non-answer.

Removing unused stuff is always a good move, but there are only just so many hands/eyes on this project.

There are also CVE, Vault7, etc.

Qubes just has to be reasonably secure

If headlines were security measures, none of us would be here.

Its not about binary blobs or CPU microcode updates although those are very insidious vulnerabilities. It is more about Linux itself. Linux is not inherently secure without being hardened using a long list of steps.
dom0 has a version of linux running inside it, which just so happens to be Fedora. Fedora/RHEL are linux
distributions used by three letter agencies and the code repos are potentially intertwined with those agencies.

It is really an issue with the unhardened nature of Linux itself, not specifically Fedora.

The other question is, how does this compare with other virtualization tools like KVM, or QEMU?

There is a very good article on Linux’s general insecurity here:

https://madaidans-insecurities.github.io/guides/linux-hardening.html#choosing-the-right-distro

The other question is, how does this compare with other virtualization tools like KVM, or QEMU?

What do you mean by “this”? What are you comparing?

If you were to make your way to the nealr Substack you’d find an article entitled What Hunts You? No hot link, since this is the paranoia zone, you’ll have to navigate there on your own :slight_smile: If you don’t understand who your adversaries are, you can’t begin to defend yourself.

Some bona fides, with the intent that my followup questions have some weight to them.

I provided the startup environment for and later quit Project VIGILANT over the handling of the Chelsea Manning case.

If you want to see the white paper that now Senator Jonathan Ossoff circulated on Capitol Hill regarding the need for hearings on HBGary’s infowar schemes against the American people, as the original author, I’ve got a copy of it handy.

I can round up receipts on the protection of Marine Corps whistleblower Franz Gayl, as well as the ones where CIA whistleblower John Kiriakou didn’t get sent back to prison, because someone knew where to send him to get a job. Anything else I’ve done in this area was anonymous.

The origins of the January 6th Capitol Siege were with the Council for National Policy. They had an effort called Groundswell back in 2013, that got bowled over thanks to a series of articles in Mother Jones. Not my work, but I’ve become the publicly known keeper of the original documents, if you’d care to see them.

Some other stuff has happened in the ten years since then. Ask your friends in the neighborhood about me.

That being said, I am struggling to see how a binary blob in dom0 is going to turn into a problem for any journalists I may know, or Ukraine supporters who legitimately need to worry about FSB/GRU/SVR, or researchers in the Arab world, or civil society activists facing cartel violence.

If you read military briefings (which I do) there’s always a “So what?” at the end, sometimes it’s even that explicit. All I’ve seen thus far are theoretical concerns with huge gaps in the execution chain that would be required for this to be an actual concern.

Step by step, how does the binary blob bite someone doing work that would draw a “by any means necessary” response from a nation state?

What I mean by “this” is Xen/QubesOS. I know that Xen is a bare metal type 2 hypervisor and that KVM and QEMU are linux packages which run on a host Linux distro like fedora/debian, etc. So they are different in that sense.

My friend, this is the methodical and necessary process of identifying potential (meaning it has the potential to be a source of vulnerability), that doesn’t mean it actually is one. But that potential source of vulnerability
still does need to be examined.

RHEL/Fedora are used by three letter agencies all over the world and some journos/activists/hackers
increasingly have three letter agencies in their personal threat models.

The other issue is simply, why choose Fedora in the first place? Fedora isn’t particularly well known for security as a linux distribution (remember that linux is NOT inherently secure without following a long list of hardening steps). Fedora (and by association Linux and the linux kernel and all of its included kernel modules) is not Alpine, hardened Gentoo, or Kicksecure, so why should it even be considered a candidate
for inclusion into dom0? Its a perfectly reasonable question.

So what has Xen to do with minimizing dom0? What relation do you see?

Xen is a part of dom0 and has its own potential attack surface in the form of the various virtualization/networking/driver libraries it uses:

XAPI
xl, xend
xenstore, xenbus
Libvirt
various hardware drivers (there is no list of drivers that Xen uses to initialize bare metal hardware, which
is also an issue)
kernel modules

@nealr

I already answered your question the way I understand it. I claim no expertise or reputation whatsoever.

You are welcome to answer the questions based on your expertise and background.

Its just a way of documenting the necessary questions to ask about which libraries/drivers/kernels could be attack surface. Its not anything personal, its just about documenting everything so that it is, well, transparent
and documented.

A long time ago I was quite “technical”, deeply focused on system mechanics, and almost unaware of those using the systems I was tasked with maintaining. Such is the life of the mildly autistic young engineer.

Today about four out of every five people I talk to see me as some sort of expert, and for them I am - because I will listen carefully, “ride along” while they work, evaluate tools and methods, and I am absolutely relentless when it comes to heading off trouble. But I am much closer to the end of my career than the beginning, so I try to find places where young people are solving complex problems, and I pick through what they’re doing with an eye on what those in the field can actually use.

This thread caught my eye because it 1) appeared to be a issue in the foundation Qubes 2) that would only affect those in the most dangerous of places 3) but which could be remediated by scrubbing dom0.

Reading further, I find this one has been talked to death long ago, the vulnerabilities are such that other terrible things will have happened before it’s exploitable, and the long term plan is replacing Fedora dom0 with Alpine, or perhaps an Qubes internal minimalist distro.

So while the reason this thread exists IS a problem, it’s already well understood, it’s highly unlikely to be an operational issue, and the project managers have a solution on the roadmap. The audience to whom I am responsible do not need to worry about this.

Qubes is an absolute riot of innovation, and conversations like this are part of that. But another part of this riotous environment is that people who should be using Qubes aren’t, because if I’m puzzling over what to do and why, a South American journalist or Ukrainian refugee will simply throw up their hands and keep using what’s familiar.

I am grateful for the amazing work that’s been done on Qubes, but I see a lot of need for clarification and standardization, too.

1 Like

What’s the solution? Where is that posted? On Github? Part of the reason is usability, there is a big learning curve. That means a large body of documentation and documented troubleshooting needs to be made available so that its easier to solve problems.

The other thing is, Fedora/RHEL is quite a large distro and it does have documented affiliation with three letter agencies.

The project managers have a solution on the roadmap - an eventual minimal distro, perhaps even internally maintained, that will replace Fedora in dom0.

I would need to see a very specific issue with Fedora/RHEL before that would cause me concern - corporate players willing to go along to get along with repressive regimes are a much bigger problem IMHO. What you’ve said there is the “TLA cooties” trope. I get along fine with the retired CIA/DIA/SOCOM people in my circles. On the other hand, I’ve made a stream of OIG complaints against the Dallas FBI field office since 2012, and that might be related to my chasing the last former FBI agent out of Congress back then :slight_smile:

I’m not opposed to authority, I’m opposed to the corruption of authority.

It would, I mean it would just simplify everything to not use Fedora (which is maintained by RHEL, which
is a private company). So yeah corporate players (like for example RHEL) could be coerced into creating vulnerabilities, or divulging already known vulnerabilities.

The migration to a small distro for dom0, perhaps internally maintained, is already on the roadmap. They have not prioritized this and I think we share the reasoning on this - it’s a theoretical concern that’s difficult to envision being employed in the real world.

If the IRGC selected Qubes to run centrifuges at Natanz, that would be one thing, but that’s not the case. An individual running Qubes who actually qualifies as a target for such high level attention exists in a context. That context includes some amount of counter-intel functionality. Kinking Fedora to kink Xen to kink a part of Qubes that default has no network access … and then do what with this access? And for how long? Without being noticed by anyone else in an environment full of hardened, reactive targets?

I’m sorry, but my troubles start with Ukrainians who can’t be convinced to stop using Telegram and this seems like something I’d file in the same folder as Carrington Event contingency plans.

1 Like

I guess the point of the thread is to map and understand the attack surface (linux packages, drivers, kernel modules, libraries) inside of Xen, and that includes Fedora. Swapping out Fedora is the low hanging fruit in terms of removing attack surface. Xen is another attack surface.

On a side note, could a Saltstack formula be used to minimize the dom0 codebase?

People see, but somehow oversee lack of HR not only for this, but for even more important things at each given moment. To me, it’s already amazing Qubes got this far with a few people available.

2 Likes

Xen Project Beginners Guide explains how to set up things with Debian.

Xen is a part of dom0

I don’t understand how.

Xen is the hypervisor. Dom0 is a VM - yes, a special privileged one, making Xen usage possible, but still a VM. As the Xen wiki explains, “Dom0 forms the interface to the hypervisor.” How can the hypervisor be part of the VM?

https://wiki.ubuntu.com/Kernel/Firmware#How_is_Firmware_Used.3F

https://fedoraproject.org/wiki/Changes/Linux_Firmware_Minimization

Of course. Dom0 controls Xen, it obviously doesn’t “contain” it.

1 Like

Xen Project Beginners Guide

This can be done using the dom0 cli in QubesOS?

I think what would be a smart idea is to have the dom0 OS be switchable by way of the Qubes Manager,
you right click on the dom0 VM and go to settings, then change the template to a template you have installed.