"But why trust Fedora?"

User Support General
1

Hi,

I am looking for information which is not available in the docs. More specifically:

We don’t even have a clear explanation of how Fedora was chosen. The question “But why trust Fedora?” (i.e. why exactly Fedora and not anything else) is not answered at all. This

“We had to trust somebody as we are unable to write all the software from scratch ourselves.”

only explains that the problem is externalized because of resource limitations, not because of safety (which would be more suitable for a security-focused OS). It does not show what research has been done, what analysis and comparison, on which the decision is based. I am not saying such analysis has not been made by the team (and I am not saying it has, as I don’t know). What I am saying is there is no info about it in the docs.

While the limitation of resources is perfectly understandable, IMO, the user still deserves to know about the actual process of trusting exactly Fedora, especially considering this info.

Further the same section says:

“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.”

So, it seems the generic “trust Fedora” and “somebody” mentioned above is trust only in the authors of the installation scripts of Fedora and nothing more. No reasons explained. There is no mention about the security of the build process of the particular distro of choice, or about potential insecurities in the way software is distributed, compared to alternatives.

IOW, this peculiar “trust in Fedora” makes it difficult to understand how one trusts something as a whole while not trusting its essential components, allowing these same components ultimate (unrestricted root) access to the AdminVM, advising in parallel that “it is important to install only trusted software in dom0.”

Considering the above, what is “trusted software”? What is the process of trusting? What are the criteria? Yet another mystery in the Qubes OS docs.

Can we have all that clarified?

4 Likes
2

I’d say it’s a serious distribution that have been around for a very long time. It’s backed by a major company. It provides SELinux. Linus Torvald uses it.

4 Likes
3

The devs picked the distribution they used.

4 Likes
4

I’d say it’s a serious distribution that have been around for a very long time.

I was wondering why exactly it, considering there are others matching what you mention.

It’s backed by a major company.

Many would consider that the opposite to trustworthiness, considering also the major company partners with government agencies.

The devs picked the distribution they used.

So, after all the in-depth security research, there was no analytical process in regards to the distro of dom0 but just one person who just “liked it”, i.e. not even “we” (as the documentation says), and that stayed so for 10+ years?

3 Likes
5

I’m not part of the development team, I’m just guessing.

2 Likes
6

I remember mentions of Fedora providing a broader hardware support than say, Debian at any point in time.

I didn’t search specifically for that, so I’m sure it will show up in one of the main conversations on the topic if you do… IIRC it might have been in the corresponding “why not using ” issue in GitHub.

7

I remember mentions of Fedora providing a broader hardware support than say, Debian at any point in time.

I remember that too but it is rather related to functionality, not to trustworthiness in the context of security, as a project goal.

I didn’t search specifically for that, so I’m sure it will show up in one of the main conversations on the topic if you do… IIRC it might have been in the corresponding “why not using ” issue in GitHub.

I don’t know which issue you mean (I found only this one), but from what I read here, I understand that it actually is what one person liked at certain point in time and that’s it. No more info. Compare that to the excellent work of Whonix devs. It is not particularly focused on trust but it provides enough detail about criteria in relation to project goal, current status and future considerations.

1 Like
8

Right. I arrived at the same conclusion. While I do respect and appreciate the work put into creating QubesOS, I don’t like the OS choice for Dom0.
Speaking strictly for me in particular, I can achieve the same level of privacy and security by running Void Linux + kvm + Whonix for kvm, on the same hardware!

2 Likes
9

Unfortunately that wouldn’t scale for the security level some users need. That would be hard for you to create something such as sys-net or sys-usb.

Qubes OS has flaws, but it offers the best privilege separation an OS can offer, and it does for free.

Up to the users to decide if they really need this, or if running VMs from Linux would be enough for them. I guess this setup is underrated / overlooked by many Qubes OS users.

2 Likes
10

Correct! That’s why I wrote “Speaking strictly for me in particular” :smiley:

2 Likes
11

There is no reasonable security if your hardware doesn’t work.

One reason, I guess, to choose Fedora might be that the package metadata are signed:

Another point is that Fedora supported the efforts toward reproducible builds (but not anymore).

Another relevant discussion:

5 Likes
12

How much does Qubes really trust Fedora anyway? By default, dom0 doesn’t have network access. I guess, as dom0, Fedora could attach itself to a network qube, but then the questions become:

  • How would someone get a piece of malware into dom0?
  • Once the malware is there, how would someone trigger it?

I think the piece of software that QubesOS must trust above all others is Xen. And there, the only answer I can think of is that, to the best of my knowledge, none of Xen’s competitors are libre.

3 Likes
13

Proxmox is build on open source software.

2 Likes
14

There is no reasonable security if your hardware doesn’t work.

This makes no sense, forgive me - neither as an argument in the current context, nor in general. Because:

  • InfoSec simply has no meaning without the technology which handles it - neither “reasonable”, nor any other. It is like discussing the most suitable swimming styles in the middle of a desert.

  • A working hardware per se is not the ultimate factor for security (“reasonable” or any other). Example: Some hardware can be used only with Windows. Other hardware can be used only with VMS. Both cases have working hardware but the level of security (and the purpose) are very different.

So, the overuse of the magic word “reasonable” as an universal argument is not always reasonable.

Another relevant discussion:

Same link from above :slight_smile:

15
  • How would someone get a piece of malware into dom0?

Through updates.

  • Once the malware is there, how would someone trigger it?

Through a system process or user initiated event.

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