create or fork a Linux distribution for default use by App Qubes for better security

[adrelanos]

The problem you're addressing (if any)

Qubes OS is marketed as "a reasonably secure operating system", leading users to expect comprehensive security hardening across all aspects of the system. This includes a hardened default browser and other Template hardening. However, the current default templates, particularly for default App Qubes, often include software with suboptimal security (and privacy) settings. This creates a disconnect between user expectations and the out-of-the-box experience.

Here are some examples. Quote Is there a reason Firefox needs to have vulnerable insecure settings in the templates? and Is Firefox really an appropriate default browser for Qubes?:

• Firefox comes configured with worst privacy settings

• When I first installed Qubes and I saw Firefox was preloaded I did assume it would have default security setting to be more secure out of the box due to the nature of the system. It was kind of shock to me that it was just setup like a straight download off Firefox.

• why the hell is Firefox allowed to be the default browser on a privacy/security OS when every time I launch it it wants to call all of its friends back home? Literally all of them, even its grandma.

It is currently not possible to address this issue in Debian, Fedora Templates, because of the related Qubes FAQ: What is Qubes’ attitude toward changing guest distros?. The policy of respecting distribution policy is in direct conflict with Qubes making changes for customization (selected default installed packages), usability (Qubes tools integrations) and security hardening.

Example Qubes tickets which can currently not be implemented because of this policy.

• https://github.com/QubesOS/qubes-issues/issues/2238
• https://github.com/QubesOS/qubes-issues/issues/1885

This was confirmed by @marmarek in https://github.com/QubesOS/qubes-issues/issues/8730#issuecomment-1828296135.

As you can see, in both cases we in fact did not include them, and in the first case it's even explicitly discussed if that wouldn't be against what Debian is.

Fork in this context only means to have for example a Template based on Qubes Debian template, with a distinct name, where security-hardening by default would be permissible without being in contradicting with respecting upstream Linux distribution policy. No other gigantic steps (such as forking all of Debian archive packages.debian.org, re-building all the Debian archive are suggested.

The solution you'd like

• A) Adopting an existing security-focused Linux distribution as the base if any suitable exists; or
• B) A fork of a base distribution by Qubes for the purpose of security-hardening it by default and use it by default.

This new template would:

• Have security-optimized default settings for browsers and other key applications.
• Minimize autostarting services to reduce attack surface.
• Allow Qubes developers to implement security best practices without conflicting with upstream policies.

Other alternatives:

• C) Reject use of a security-focused Linux distribution by default (due to lack of resources) and improve Qubes branding to reflect that this is out-of-scope. (non-ideal)
• D) Abolish "respect distribution culture" policy. (non-ideal)

The value to a user, and who that user might be

• Aligns the out-of-the-box Qubes experience with user expectations of a security-focused OS.
• Provides better default protection for users who don't customize their templates.

Completion criteria checklist

[rapenne-s]

The solution B seems the most reasonable to me, and should require little maintenance once the work is done.

Nobody seems to complain against Debian or Fedora, they are working well and fit most users (long lived released and stable vs bleeding edge every 6 months). The problem pointed out by some Qubes OS users with these templates being the defaults settings, if there are no other "grievances" then injecting new defaults seems the most reasonable solution in term of benefits vs time spent.

I am not sure how to deal with secure AND privacy oriented at the same time though. A privacy oriented template may hinder the usability aspect if it goes too far, and people needing a privacy oriented template will want the "most private" experience, while it's fine, it may provide a really poor experience for people looking for a secure system. For instance, I mean by "too much" that if you provide web browsers defaults with all features disabled, many people are not going to use it. While it would be fine to disable a few things like telemetry, acceptable in a security oriented template, it would not be enough for privacy oriented users.

It would be interesting to list all the changes that the community would like to see and try to see if all of them could fit in a single template and still be usable by everyone.

Also, what's wrong with whonix as a privacy template?

[marmarek]

It looks like most points @adrelanos is talking about is actually about privacy, not really security. And we explicitly recommend using Whonix qubes if one cares about privacy the most: https://www.qubes-os.org/faq/#what-about-privacy-in-non-whonix-qubes I know some users confuse those two, but they are separate and even sometimes contradicting (for example updating the "safebrowsing" list is likely considered one of those "phoning home" connections, but its use actually increase user's security). So, there is no need for yet another "privacy-focused" template - we have Whonix already.

As for yet another, template, more "security focused" instead of "privacy focused", TBH I'm not sure if that's a good idea from the users point of view. Our current policy does allow some modifications (for example we disable thumbnail preview in file managers). But please also remember our goal is to create a system that is not only "reasonably secure", but also usable and convenient to use. This does include not breaking users expectations how things work (if possible ofc). See the rationale for this policy (in the very same link) - it isn't just to make it easier to developers, but also easier to the users (and in fact, sometimes it does make it harder for developers - see all the needed changes to get SELinux working in Fedora, to match what upstream does).

I'm not completely opposed to yet another template, with more tweaked settings. But I do think the defaults should be easy to use - Qubes OS already requires a bit different thinking by introducing separate isolated compartments, changing how things works compared to plain Debian or Fedora even more (for example, by not starting installed services by default) will make it even harder to use for new users. Some changes, even if theoretically increasing security (in some metric) in practice may have the opposite effect if they make it harder to use. A good example is hardened file copy in R4.2 - theoretically stricter file names validation should make it safer, but in practice it blocked also several legitimate cases (legitimate use of right-to-left text etc) and users workaround the issue by copying tarballs or zips and end up without any of the protection that qvm-copy provides... You can watch "Bad UX is Bad Security" presentation from Qubes OS Summit 2023 (or similar from FOSDEM 2024) for more examples and explanation. If some change make things safer, while not making it harder to use, I'm much less opposed to such changes.

[adrelanos]

@rapenne-s

A privacy oriented template may hinder the usability aspect if it goes too far, and people needing a privacy oriented template will want the "most private" experience, while it's fine, it may provide a really poor experience for people looking for a secure system.

The same issue can happen if setting too much secure settings. Then other things will break.

For instance, I mean by "too much" that if you provide web browsers defaults with all features disabled, many people are not going to use it. While it would be fine to disable a few things like telemetry, acceptable in a security oriented template, it would not be enough for privacy oriented users.

Yes. Privacy is even harder than security.

Also, what's wrong with whonix as a privacy template?

Nothing. (I am maintaining Qubes-Whonix.)

I wrote this feature request because I believe among other users that it would be good to have more security hardening inside the VM by default. A security-hardened Template where its traffic will not be torified.

@marmarek

It looks like most points @adrelanos is talking about is actually about privacy, not really security.

I wonder how that impression has been created. Actually, this ticket is about security.

In the ticket I wrote "security (and privacy) settings". Privacy inside parentheses. Now I think I should have avoided to mention privacy altogether to avoid any sideline discussions.

The example tickets I linked are purely about security enhancements but those who are contradicting Qubes respect upstream policy.

(for example updating the "safebrowsing" list is likely considered one of those "phoning home" connections, but its use actually increase user's security).

Arguably also worsens security. It attempts to enumerate badness. Blacklist approach. hence will remain incomplete. On the other hand, string parsing of a specifically crafted safebrowsing list could exploit the browser. This code might also not be very well reviewed because reviewers might assume that "only trusted parties can update that list anyhow".

I'm not completely opposed to yet another template, with more tweaked settings. But I do think the defaults should be easy to use -

Reasonable.

[marmarek]

I wonder how that impression has been created. Actually, this ticket is about security.

Examples you brought up are mostly about privacy, including quotes like "Firefox comes configured with worst privacy settings" (which BTW is quite subjective, it's simply default configuration and compared to other browsers, especially Chromium-based, Firefox actually have quite decent defaults privacy-wise)

[adrelanos]

I see. The many (~ 45, see [1]) connections Firefox establishes I consider having a negative security impact. This is because string parsing is probably involved in each case. Leading to too unnecessary and much bigger attack surface.

How Firefox implements it now is intransparent as in counterproductive for reproducible builds. Any volatile files the browser may need (blocklists, https revocation lists, and whatnot) should be deployed through the usual system's package manager. Then all users can download the same files/packages. Users could optionally download these updates Tor. Targeted attacks against specific users would be much harder and a higher risk of detection. The having to download a ton of files all the time is just bad design.

---

[1] See screenshots posted here:

• https://github.com/arkenfox/user.js/issues/1807

[marmarek]

This is because string parsing is probably involved in each case. Leading to too unnecessary and much bigger attack surface.

Given the browser's primary task is parsing untrusted content received from network, I don't think a few extra strings is a concern. If it can't do that, you probably shouldn't connect such browser to the network at all...

Any volatile files the browser may need (blocklists, https revocation lists, and whatnot) should be deployed through the usual system's package manager.

That would be actually be worse option, as it would be much less frequent update. Many of those lists are most effective for blocking fresh attacks (until attacker migrate to another, not blocklisted yet, domain).

Anyway, it's getting offtopic.