"But why trust Fedora?"

User Support General
21

I think the point was that packages from official distro repositories are trusted in dom0 as they are in templates.

They are not. Read the paragraph quoted in the OP.

Given that the QubesOS devs intentionally choose distro versions that have ceased receiving updates, “latest and greatest” with a short lifecycle is what you want.

I don’t know what you are talking about. The info others shared above clarified there were no devs, no intention was explained and nobody was asked “what do you want?”

Simply think about all the hardware issues etc. if an old Debian distro version were used, given their much longer support cycles.

The fact is: in Qubes OS I cannot use a well-known FOSS-friendly hardware, which I have been able to use without issues on 15+ years old computers running other distros (including 32-bit). If hardware utilization is really a priority, this is quite confusing, especially considering all the talk about how careful one should be with USB.

Your links are […]

a short way to avoid off-topic, so you are right:

neither of those are the kind of repos that are relevant to this discussion IMO;

In conclusion these examples have not shaken my trust in the approach used by QubesOS

Since I still haven’t seen the approach explained anywhere, I really don’t know what you mean.

22

What I get from that paragraph is that there is implied trust that Fedora packages (and Debian as regards templates, for that matter) are not crafted by the Fedora team to infect the computer when being installed. Using them is another matter, of course, and Marek has said that once dom0 is truly only an admin VM (so stable sys-gui, sys-audio and some other thing IIRC) then a minimal dom0 will be considered.
It would also be nice if you were a little more charitable or at least follow the thread…the post I quoted was a reply to this post, which talks about AppVMs getting infected as a result of a package update of their template. So we are talking exactly about the kind of case where Fedora / Debian packages are trusted (their installation, not their use). I was trying to explain the implication of what that user was saying.

Consent doesn’t have to be explicit and articulated, though it usually is a good thing if it is. Clearly the devs didn’t have a problem with Fedora-based dom0. There is also no general principle saying that non-members have a right to vote on this or that aspect of the project…even members don’t necessarily.

Just because a distro is more up to date regarding hardware compatibility doesn’t mean it now supports all hardware. And it’s not just about hardware, either…lots of packages are more up to date in Fedora 37 than in e.g. Debian Stretch.

3 Likes
23

I’m not sure what the point of continuing this discussion is.

The topic started with a question about why Fedora was chosen. It seems like that question has been answered: it was a somewhat arbitrary decision, but most people are fine with it because it’s a large/well-known project meaning that there are a lot of eyes on it and a lot of people depending on it being secure.

There are valid reasons to want to use a different distribution just as there are valid reasons to want to use Fedora. The QubesOS project is not responsible for catering to any particular person’s preferences, and where a decision is ambiguous the maintainers need to be able to make judgement calls based on the relevant tradeoffs and available resources. If they cannot do this then there is no QubesOS at all.

Personally, I would also like a different base distribution. The project graciously provides all of its source code under free licenses meaning that anyone is free to do the work required to support a different distribution. Yes this is difficult work which takes a lot of time and expertise. That is not a burden that the QubesOS is imposing on anyone, it is simply the nature of the situation we are in. There is no justification for demanding that this burden is taken on by the QubesOS. It might make sense for this to happen at some point under some specific circumstances, but a general “I think Fedora is sketchy” is not an argument, it’s fearmongering.

3 Likes
24

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.

2 Likes
25

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.

1 Like
26

It’s surely related to version 1.0 released in 2012 :slight_smile:

1 Like
27

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.

3 Likes
28

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.

1 Like
29

I don’t think they are going to make dom0 OS independent, but if dom0 becomes less overloaded, than the OS shouldn’t matter.

30

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.

1 Like
31

Doesn’t this answer your question?

To me, it was pretty clear from this text.

32

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.

1 Like
33

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.

1 Like
34

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.

35

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.

1 Like
36

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:

  1. all packages that are actively used for the standard functionality of QubesOS and the templates are trusted (which excludes most code of regular packages in total)
  2. all regular distro packages’ installation scripts are also trusted
  3. “trusted” doesn’t necessarily imply trustworthiness
  4. since “trustworthy” is what we want, there needs to be an explanation: it is simply a) the lack of resources regarding point 1. and b) an expectation that Fedora’s installation scripts are not crafted to be malicious regarding point 2 (so for b) it seems there is actually more trustworthiness assumed by the QubesOS team).

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.

4 Likes
37

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).

38

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…

1 Like
39

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.

40

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.

2 Likes