This is a popular one. Every now and then there is another post asking for the posters favorite distribution to become dom0. Other frequently complain about the age of Fedora in dom0. The answers to all of this is covered in the FAQ of course:
Current news strongly suggests to me that I actually WANT the distribution in dom0 to be EOL, in which case it would ONLY receive XEN and Qubes OS related updates authored or at least reviewed by the Qubes OS team.
Even better, once the hardware handling has completely moved into dedicated domU (sys-net, sys-usb, sys-audio, sys-gui) I really want dom0 to be an extremely minimal distribution maintained, reviewed and audited in it’s entirety by the Qubes OS team. I have no idea if this is feasible technically and from a resource perspective.
In any case, the questions for this thread are:
What are the implications of rogue authors OUTSIDE of the Qubes OS team to dom0 in particular?
What are possible counter measures with a REALISTIC/TOLERABLE impact on the core teams work load?
If you choose to post to this thread please take the time to properly reason your opinion and link to sources for your statements. This forum is recently flooded by people claiming all sorts of things without any evidence or even basic understanding of how Qubes OS works. We can do without that here. Thank you!
I’ve reading 3 times in the main question, looks like the question is aimed at the qubes team? isn’t that mean it should be posted somewhere… at least in qubes-devel?
If I allowed to post :
Qubes os is based on open source, which in my understanding everyone can contribute or in some os needed to pass some test (could be contribute continously for some years) to contribute into core code. So when the question asked for implications, it should be zero since marek is the lead developer and has stated that before requestion for pr, one should discuss first.
I certainly hope for some input / opinion from them if they find the time. But no, the discussion is meant for all.
I understand and are much less worried about packages that come from / are build by the Qubes OS team. I have to trust them in order to use Qubes OS, so worrying about these would be a waste of time. Of course unintentional issues can and will happen … but that is not the topic.
My concern are packages that come from the Fedora project, which does not code review each and every package they deliver. So if a rogue author as the one in the linked story decides to add malicious code into a package that then gets hosted and delivered by the Fedora project … it would end up in dom0.
That’s why I am starting to see an advantage in dom0 being EOL, which means the Fedora repositories should remain static. Maybe they aren’t even polled? … that’s what I would like to understand and discuss.
This has nothing to do with open or closed, but with trusting that the packages we receive and install in dom0 are not malicious. The problem is the same whether the code is open or closed, it’s about importing dependencies that are not explicitly trusted.
I seem to recall @marmarek and/or Joanna once describing the eventual goal as making dom0 (or, perhaps more specifically, the AdminVM) a “hermetically sealed” environment with which the user never directly interacts.
That direction will be great since it will open possibility to use more tightly tied (I mean sometimes proprietary, sometimes not mainstream) drivers without possible compromising of whole system. I relay want give NVIDIA drivers, or TLP a try on Qubes but don’t want them in my dom0.
I’d have to agree with you @Sven. If I had a choice of OS for dom0, I’d either pick something like Debian with security updates, or an EOL Fedora. Even a Buildroot or Yocto would work, too.
It all depends on what devs are comfortable writing patches for. Zero-days come from anywhere, and original creators are unlikely to patch EOL software if one is discovered. This could potentially force devs to patch software they’re completely unfamiliar with, and I know very well how frustrating it can be when you are forced to do something that’s out of your area of expertise…
@adw, If everything the user interacts with is in a VM, then dom0 would basically become like a daemon, requiring no user interaction at all. This is kind of what Xen is at the moment. Most users probably forget half the time they’re using Qubes that it’s sitting on top of Xen
I’d be ok with that, as long as it didn’t break anything (suspend/resume, GPUs, hardware, battery life, etc.), and as long as the user could still open it back up for fixing/tinkering, provided they knew the risks.
Which brings me to an interesting point. Is there anything to be said for having an immutable filesystem in dom0, similar to wifi router images or the Steam Deck?
Oh boy was that a rabbithole. I had no idea just how many cases of deliberate malicious code has happened. Though I must admit I can understand why the maintainers would be upset by multi billion dollar companies using their code for free. Is there any way to protect yourself from something like this other than reading the source code of literally every single package and dependency you ever install?
As much as I do keep stuff compartmentalized, even I would be pretty pissed if I had a template wiped because my vpn happened to default to some arbitrary country
There’s been some talk about the possibility of using an immutable operating system like Fedora Silverblue, but I’m not keen on the details. @Demi might be able to say more about this.