"But why trust Fedora?"

User Support General
16

This essentially means that you expect active malicious actions from Fedora. This can’t be excluded of course, but looks very unlikely to me. Do you have any examples like this in the FLOSS world?

It is in the particular example of Qubes OS and average journalist/activist. If they can’t run Qubes at all, they will run another, much less secure OS. If you personally require a much higher security level, you should be able to ask a professional to tweak Qubes for you (or do it yourself). Decreasing the security for average people while increasing it for the heavy threat models is AFAIK not the goal of Qubes OS. Hence “reasonably secure OS”.

1 Like
17

A malicious package doesn’t need dom0 to end the game. Updates could affect a template VM just as easily as dom0 (maybe even more easily, considering the number of packages that get installed). If a template VM installs an infected package, then all app VMs based on that template will inherit the infection. At that point, an attacker might not even care about dom0.

2 Likes
18

What an attacker “might not” do is of little consequence in InfoSec. Every attack “path”, be it a narrow pathway or a 100m wide boulevard, has to be addressed.

2 Likes
19

This essentially means that you expect active malicious actions from Fedora.

No, it means I answered the question and nothing more.

I don’t know what your understanding of “active malicious actions” is. Things can be quite invisible.

This can’t be excluded of course, but looks very unlikely to me.

It is neither likely or unlikely to me. To evaluate that, I would start with considering the environment where it may happen: a centralized controlled one (company with publicly declared state partnership) vs a decentralized community of volunteers. Each one has its pros and cons.

Remember also that Fedora is somewhat latest-greatest style distro. Usually stable well-tested distros are preferred where security is important which adds to the mystery of the current choice.

Do you have any examples like this in the FLOSS world?

It is in the particular example of Qubes OS and average journalist/activist.

There was no example in what I answered.

2 Likes
20

I think the point was that packages from official distro repositories are trusted in dom0 as they are in templates. While that may not be ideal, there is really no alternative; let’s say the Qubes team had 1000 times more resources available than is the case and so could produce its own linux distribution or even some other OS for dom0 as well as the templates; this would still only shift the problem, as now the Qubes team would be 1000 times larger, so instead of trusting the teams of QubesOS, Fedora, Debian and a whole bunch of other people who contribute to the Linux kernel and the various packages etc., you now have to trust the thousands of new Qubes team members. How do you know that they are more trustworthy than the other mentioned groups?

It would be great if there is eventually some kind of audited, proven AI white hat / source code auditor, as that may allow some kind of more or less objective measure of how problematic a complex piece of software is. But until then…you’ll have to trust many people.

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. Simply think about all the hardware issues etc. if an old Debian distro version were used, given their much longer support cycles.

Your links are also a bit nebulous…the first actually explicitly mentions PyPi and NPM in the “what is a malicous package” section, as those are indeed the most problematic in my understanding, but neither of those are the kind of repos that are relevant to this discussion IMO; the second link also mentions NPM as being the most problematic, while the claim of “1 in 5 bugs were planted maliciously” is not substantiated and their link to the report that is supposed to prove it is dead (links to a different report)…intention is not easy to prove so I’m very skeptical of that claim. The last link produces only 3 examples, 1 from 2003 and 1 not maliciously planted (at least no one has proven that it was maliciously planted); the remaining example is indeed interesting, but was detected before it could spread far and wide.

In conclusion these examples have not shaken my trust in the approach used by QubesOS, but as I said above, it would of course be nice to have some kind of objective and comprehensive measure of code quality that can be trusted.

4 Likes
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