What distribution with pre-2012 Xen dom0 kernel support would you pick?
Your options would probably be limited to RHEL/CentOS, SUSE, Debian, or Fedora.
Picking one of the enterprise distribution for a desktop system doesn’t make much sense.
I’m a Debian user, I don’t have a single Fedora VM except for dom0, I would probably still pick 2012 Fedora over 2012 Debian do to hardware support and the release cycle.
Sorry, maybe I’ve missed something obvious/well-known. I’m pretty new to Xen. Why is 2012 important? Both the Xen and Fedora versions that QubesOS runs are much more recent than that.
It’s surely related to version 1.0 released in 2012 
As @palainp said, the initial release was in 2012.
There is source code copyrighted 2010, so the “point of no return” moment was likely much earlier in the development.
Just because something works with Xen today, doesn’t mean it was a candidate during development, when the decision was made.
Some time ago there was a thread I read about something similar, and someone from the official Qubes’ team said that there is work in progress to make dom0 to be OS independent in the future, similar to what domU has.
I can’t find that thread, perhaps someone can point out and help.
I don’t think they are going to make dom0 OS independent, but if dom0 becomes less overloaded, than the OS shouldn’t matter.
It seems like that question has been answered
The problem is that this answer does not resolve the confusion in the docs. There is no clear answer to:
Considering the above, what is “trusted software”? What is the process of trusting? What are the criteria?
This is the only thing I am interested in.
Found that post I was talking about: Dom0 Security - #2 by Sven
The Qubes OS project is actively working on moving more of the hardware handling into dedicated qubes: sys-net, sys-usb, sys-audio, sys-gui, etc. Once this is isolated in a qube you can choose which distro to use.
That been said, this is from June '22, and discussions regarding this are at least from 2016.
Hopefully, the ability to choose the dom0 distro will be prioritized to minimal build specific to Qubes OS or even more shady Qubes air.
Doesn’t this answer your question?
Not really (and it is not just one question). I will explain, in case it is not clear why.
(A) What you quoted suggests that all Fedora packages are trusted implicitly.
(B) What the doc says is that the only actual trust is that Fedora’s installation scripts are non-malicious.
My understanding is that, unlike (A), (B) excludes the essential package contents because:
Package managers don’t verify each line of source code. The upstream is not part of the trusted installation scripts and can be considered part of the distrusted infrastructure, which has the goal “to trust as few entities as possible”.
Building, packaging and signing are very much automated and non-transparent to the end user. (C) To my mind this is part of the distrusted infrastructure too, however it seems trusted by Qubes OS devs, although not mentioned in the docs.
IOW, a trusted non-malicious script can install a malicious package. This is distro agnostic (perhaps Gentoo may be considered an exception in regards to building), which leaves unclear what selected distro’s particular advantages in regards to the above are.
The recommendation “it is important to install only trusted software in dom0”, mentioned in the OP, contradicts (B) as it because “software” includes package contents too. That’s why it is not clear what “trusted software” means and the rest of the questions in the OP. If the devs don’t trust the actual package contents but only the installation scripts, how is the user (being a non-expert) supposed to trust software?
We have been told again and again that if anything reaches dom0, it is “game over”. Assuming Qubes-typical isolation is flawless and the user doesn’t do anything stupid, the only way for anything to enter and touch dom0 is through installation/updates, i.e. - Fedora. IOW, dom0 is as secure as the chosen distro. This also contradicts (B), as what is allowed in dom0 is surely bigger than just installation scripts. So, along these lines @Bearillo is right and trust expands on package contents (including binary blobs) and applies to all packages, i.e. all Fedora software is trusted and renders the “install only trusted software” recommendation meaningless.
This is bothering me, because its superficiality doesn’t match the fine in-depth security research and articles which I have read by Joanna (hats off), which are the actual reason I decided to use Qubes OS.
I am not saying Fedora is bad or good. The same can be said for another distro. That’s besides the point. I am concerned with the single point of failure in a compartmentalized system which tries to avoid it as a core principle. Suppose for a moment that a malicious actor with enough re$ources somehow contaminates the dom0 distro, which already has a huge attack surface. (I am not even asking who will take responsibility for the “like”) - What will be the result? Would it really matter how granular my compartmentalization is, how minimal my templates are, how safely I use USB and how certified the laptop is? What will be the value of all the references to theoretical lab-tested exploits have, if there is a huge open door through which gigabytes of data enter, and that door is guarded by an external entity, not by me and not by Qubes OS devs?
IMO, we have a serious problem and it is not hardware support or usability. I wish I knew how to help with that but although I keep learning things every day, it is beyond me.
Ok, but you said (or at least implied) that dom0 would need to support a pre-2012 kernel. I don’t understand the connection between the project happening to have been released in 2012 and needing to use a pre-2012 kernel. Or perhaps I misinterpreted your post.
I don’t know when they started developing Qubes OS, but there is source code copyrighted 2010.
I’m guessing they didn’t spend two years developing Qubes OS, just to switch the dom0 OS the day before release. At the point, they could have the same situation we have now, where it is too difficult to change the OS.
It’s very likely they decided on Fedora before 2012.
I think there are a lot of misunderstandings in this topic and it doesn’t seem productive to me, but since I’ve been referenced, I’ll just try to clarify my prior post by stating that there is a distinction to be made between what would be ideal (all packages being fully trustworthy due to some kind of comprehensive, objective audit) and what is actually the case (some packages are trusted, but most non-kernel code is not; the installation of all regular distro packages is, however, trusted - trusted is not the same as trustworthy).
So, having had another look at the docs:
Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for dom0 packages and for app qube packages). We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in dom0. We had to trust somebody as we are unable to write all the software from scratch ourselves. But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-exploitable. We certainly do not assume the latter.
Only install packages from trusted sources – e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and we expect that at least the package’s installation scripts are not malicious.
I interpret this as follows:
There indeed doesn’t seem to be a specific argument explaining why Fedora rather than e.g. Debian was chosen for dom0; some arguments for it have been provided here and elsewhere, but there is no complete, fully articulated position presented.
And this is why I use so many templates, built ultimately on a minimal template. Admittedly some of them have a lot of “stuff” on them but none of them bulks up even half as much (all under 3 GB) as much as debian-12-xfce (over 6 GB).
There indeed doesn’t seem to be a specific argument explaining why Fedora rather than e.g. Debian was chosen for dom0; some arguments for it have been provided here and elsewhere, but there is no complete, fully articulated position presented.
Right. And considering what we seem to agree on, it is still not clear how exactly a user is supposed to follow the documentation practically.
Just a random example: vim is not installed in minimal packages (only nano and vi), yet it is installed in dom0. Since it is obviously considered “trusted” in dom0, what is the the point to distrust it in a mini-template for the purpose of reducing attack surface? Also considering the size of dom0 and of mini-templates - aren’t the later another security theater? Questions, questions…
Thank you for clarifying. I think that my previous statement that I would prefer a different base distro needs some qualification.
I am not criticizing the original decision to base QubesOS on Fedora. I am also not saying that using Fedora as a base distro is a bad idea.
I am expressing my individual preference to use a different base distro, due to my desires and circumstances. I am not asking the project to spend resources to cater to my particular preferences. I appreciate that the project is released as free software so that I am able to invest those resources myself.
Minimal templates are not just minimal for security reasons, though that is probably the biggest goal (e.g. another being resources); it’s true that dom0 has both vi and vim, but since it’s not required to use vim (e.g. I only use vi pretty much in general, without problems) or many of the other programs that come pre-installed in dom0 (e.g. thunar), the only problem here for a user who follows the recommendations and does as little as possible directly in dom0 (and doesn’t install - with intention of using - additional packages in dom0) could arise from installation (i.e. the original QubesOS installation or a system upgrade, e.g. from 4.1 to 4.2 - this is achieved due to the devs picking distro versions that have EOLed for dom0; and I’m leaving aside the kernel updates here).
This is where my above points 2 and 4b) come in: the developers do consider installation scripts to be both trusted and - at least to some degree - trustworthy. Whether that is reasonable or not I cannot fully evaluate since I’m not an IT professional, but to me it does seem reasonable unless your threat model includes being personally and specifically targeted by three letter agencies.
An important difference between minimal templates and dom0 is that minimal templates’s AppVMs are expected to have contact to user data, which greatly increases the risk that some package’s binaries will be executed, either intentionally or inadvertently. In fact, IIRC, one of the official reasons for why minimal templates can make sense to use is “so you don’t accidentally launch this or that program”. If a user follows the recommendation of not using dom0 for anything but configuration, e.g. no viewing your screenshots there - send them to a dvm -, no using it as a vault for your secrets - use the vault qube - etc. etc., then the risk of a potentially malicious package in dom0 being “activated” through some user data being processed, is much lower than in the AppVMs based on minimal templates, because the latter do have regular contact with often at least somewhat untrusted user data. Given this important difference, no I don’t think the latter are “security theater”.
Lastly I’d like to point out that dom0 has actually been minimized a bit, just not very thoroughly…there is e.g. no firefox or thunderbird or ristretto or keepassxc etc. etc. installed there, so a preliminary effort has actually been made to remove unnecessary packages and, as I pointed out before, a minimized dom0 is going to be considered in the future once the big effort of getting GUI, audio etc. out of dom0 has been completed.
See also:
An important difference between minimal templates and dom0 is that minimal templates’s AppVMs are expected to have contact to user data, which greatly increases the risk that some package’s binaries will be executed, either intentionally or inadvertently.
As you know, dom0 can contact every data and can execute every binary in every VM. Also, a malicious package can contain no binary, e.g. it can simply replace config files with others, which would affect the way non-malicious system processes work, thus creating a mess. Things can be even more nuanced. An attack doesn’t necessarily mean data exfiltration.
If a user follows the recommendation of not using dom0 for anything but configuration, e.g. no viewing your screenshots there - send them to a dvm
The software generating the screenshots is installed as trusted in dom0. The input data (the workspace) is fully accessible to dom0 (it generates it). Therefore, the output image file has the quality of ultimate trust. So - trusted data, trusted software in the only fully trusted VM. If such data can “activate” malware, then any other data existing in dom0 can do that. Why should one send ultimately trusted data to a disposable VM - a technique aimed for untrusted data? If that is not a security theater, I don’t know what is.
no using it as a vault for your secrets - use the vault qube
Secrets are also ultimately trusted data. The purpose of having a vault domU for them is not to protect the secrets from activating malware in dom0, but to protect the secrets from less trusted domUs.
then the risk of a potentially malicious package in dom0 being “activated” through some user data being processed, is much lower than in the AppVMs based on minimal templates, because the latter do have regular contact with often at least somewhat untrusted user data. Given this important difference, no I don’t think the latter are “security theater”.
The whole idea that malware can safely exist in a passive state in dom0 and that the whole security of dom0 depends on the user being extra careful not to activate something somehow, while updates can install any new executables, including ones not explicitly requested by the user, is exactly what you don’t think it is and against all the recommendations related to that.
And why would it do that? The point I was making was about user data being processed inside a VM, such as a user opening a malicious PDF file. If the user follows the recommendations about not processing user data in dom0, how would dom0 start processing data in some AppVM by itself?
IIUC this only applies if you didn’t set up a sys-gui, which is where the QubesOS project is headed.
That does not follow…one kind of exploit being possible does not mean all other exploits become possible. The data in this case would be the specific configuration of visible GUI elements, and their content, of some VM, while the exploit would be some bug in the code that processes that data to produce the screenshot file. Let’s say there is such a bug and such data can be crafted; how does that equate some other data that has nothing to do with screenshots “activating” something?
Because viewing and editing an image file uses different packages with different code than taking the screenshot. The goal is reducing exposure: there is a difference between “only” running xfce4-screenshooter on some user data and running it plus ristretto, gimp or whatever else with that user data. Ultimately, as stated, the goal is to remove even the exposure to xfce4-screenshooter as well, which is one of the advantages of sys-gui (at least potentially; I haven’t checked exactly the implementation).
Except you will likely be processing those secrets in some way, which may include some kind of database software, editors beside vi or use gpg on it or even apps like ristretto in the case of secret images, keepassxc to conveniently organize some types of secrets etc…plus there will be the issue of getting those secrets into dom0, which means even more exposure to user code.