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.
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
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.
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
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.
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.
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?
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.
But that document describes doing it from scratch at a GRUB command line. It doesn’t describe how to convert the dom0 OS from Fedora to Alpine, for example, using Qubes manager, or using dom0.
It would be great if you could execute a commend that changes the .iso
The point is - obviously Debian is a possible option.
FWIW, I tried removing individual firmware packages in a Fedora 38 qube. It works fine and e.g. removing nvidia-gpu-firmware does not ask to remove linux-firmware itself. It is also possible to remove other individual firmware packages. So, obviously in newer Fedora versions (newer than those in dom0) some work in that direction has been done.
Re. Alpine - I have never used it. I have only read it is minimalist.
That said, I agree with the devs that before having a working GUI domain, minimizing the rest of the distro of dom0 is probably a useless exercise, as the end result would still be a too big dom0.
As a whole, it might be a good idea to see some collaboration between the guys from suckless.org and the Qubes team, and hopefully have a suckless dom0
I guess the answer you are looking for might be: they aren’t. Dom0 is based on Fedora and the devs added some 2.5k lines of their code at the beginning of Qubes, the way Whonix/Kicksecure are based on Debian and customized by their devs in different ways.
