How to minimize dom0?

User Support General
21

Why is dom0 not minimized and includes unnecessary stuff?

I think the direct cause is that some packages rely on those “unnecessary stuff”. Try to remove the package you dislike and see if something really depends on it.

How to improve that?

I’ll be grateful if you would like to take efforts to identify and remove the unnecessary packages. However keeping the minimal required packages list is a maintenance burden.

And for hardware-specific packages I do not think it’s easy to make them uninstalled by default and then install them on your demand, as it’s not easy to keep the linux kernel ( which is quite bloated with all those firmware and modules that may not be used by your hardware ) light-weighted and contain only those code that you actually use.

And I have to point out that installing additional software in dom0 does not increase the attack surface ( make it easier for random attackers on the internet to hack you ): they only mean an increase on the code that you have to trust. That’s why dom0 can use an EOL fedora release and people do not need to worry. Those random packages are not security critical. As long as they do not contain code to specifically breach Xen and send telemetry home, you are safe.

How can one use a different basis for dom0? (and why isn’t e.g. Debian the default one or an option)

22

@augsch

Thanks for your feedback.

When you put unnecessary stuff in quotation marks, do you mean it is not really that (i.e. that it is actually necessary) or something else?

I did what you suggested:

root@dom0:~ # repoquery -q --installed --whatrequires amd-gpu-firmware.noarch
linux-firmware-1:20230625-148.fc32.noarch
root@dom0:~ #

IOW, the developers have decided that it should be impossible not to have AMD GPU firmware (and lots of other) if one wants to use small part of the Linux firmware. Yes, I know firmware is supposed to run on the device’s chip, not on the CPU, but it does not remove the fact that tons of proprietary (unreadable) stuff is present all the time and it is possible a bug (or intentional exploit) to activate unknown things in unknown new ways at unknown times.

Another example:

root@dom0:~ # repoquery -q --installed --whatrequires LibRaw
ImageMagick-libs-1:6.9.11.27-1.fc32.x86_64
root@dom0:~ # repoquery -q --installed --whatrequires ImageMagick-libs
ImageMagick-1:6.9.11.27-1.fc32.x86_64
root@dom0:~ # repoquery -q --installed --whatrequires ImageMagick
qubes-utils-0:4.1.19-1.fc32.x86_64
root@dom0:~ #

Is that really necessary (in the sense - unavoidable) in dom0?

I’ll be grateful if you would like to take efforts to identify and remove the unnecessary packages. However keeping the minimal required packages list is a maintenance burden.

I am not saying I would not like to help. However, the approach “let’s remove the bloat” seems like an attempt to fix the approach “let’s have everything first”. Wouldn’t it be saner to use only what is strictly necessary instead? Isn’t that how minimal templates are created? I wonder what we can really do.

And for hardware-specific packages I do not think it’s easy to make them uninstalled by default and then install them on your demand, as it’s not easy to keep the linux kernel ( which is quite bloated with all those firmware and modules that may not be used by your hardware ) light-weighted and contain only those code that you actually use.

This raises the questions:

  • How are lightweight Linux kernels created?
  • Can’t we have the same in Qubes OS?

Many years ago, when I (like others) played with recompiling the kernel for various reasons, I remember we used to do things like having needed stuff in the kernel all the time, not-so-often used as modules, remove everything else. That gave the fastest and smallest possible, yet fully functional kernel binary.

I understand that today things are probably different, but I wonder - can’t this (or a similar) approach be used?

And I have to point out that installing additional software in dom0 does not increase the attack surface ( make it easier for random attackers on the internet to hack you ): they only mean an increase on the code that you have to trust. That’s why dom0 can use an EOL fedora release and people do not need to worry. Those random packages are not security critical. As long as they do not contain code to specifically breach Xen and send telemetry home, you are safe.

Data security is not just about keeping it hidden.

In the InfoSec CIA triad, confidentiality is just one of its aspects. Integrity and availability are the other two.

Suppose there is a bug (or unnoticed exploit) in one of those bloated libraries which damages rarely used file contents randomly. Considering dom0 has full access to everything the whole time, you can figure the potential consequences. One day one may turn on the computer and find out that old data is simply not there, the messed up copies are backed up and the backup has rotated. Yeah, nothing is sent to anyone (and you are safe from other’s eyes) but the data’s integrity and availability are damaged.

Looking at the thread you linked to, the locked in 2021 GH issue and the (already closed) issue I reported today, I wonder if anyone has considered the above.

2 Likes
23

They are depended on, so I do not actually think they are unnecessary, unless the dependency list is created by a randomly typing monkey. There has to be some reason. And the best way to check why they are depended on is to dive into the source code and go back to the time when the dependencies were added.

The definition of “strictly necessary” varies from person to person. And rebuilding every wheel for each person is what the devs cannot afford due to limited resources. That’s why your efforts are appreciated, and that’s why minimal templates are for advanced users, and that’s why there must be guides for running something based on a minimal template.

Take a look at Security-critical code | Qubes OS and you’ll find that this kind of restrictions exist since the project began. Xen contains code specific to AMD or Intel chips ( the MSR list, the scaling drivers, etc. ), and it’s expensive to tailor out exactly what code you need for your PC. So only you can serve you best.

Of course I believe that approaching stateless is better than not. But in the current situation, it should be a community project, and requires a certain level of technical knowledge to correctly apply individually.

There are just too many things that have higher priorities than switching distro in dom0. I think.

2 Likes
24

@augsch

Yes, I understand what you explain about dependencies. The problem is that even if one takes the time and effort to find the actual dependency, then what?

A simplified example: Suppose linuxfirmware uses just a single function from amd-gpu-firmware because it was easier for the developer to do that, thus creating this bloat of “have it all”. Then, on top of that more functionality is added, making the removal of this dependency even harder. If that is the actual approach of creating dependencies (as it seems), then a whole army of code re-designers and re-organizers is necessary. Not only this is inefficient, but it also seems a sign that the approach itself is wrong (in the sense - impossible). If there are a few thousand develpers adding more and more (with dependencies), a single person or a small team cannot possibly counteract that. Also, where is the good old principle “do one thing” in all that?

To my mind, starting from a base minimum is the only possibility here (like with the minimal templates).

The definition of “strictly necessary” varies from person to person.

What do you mean?

And rebuilding every wheel for each person is what the devs cannot afford due to limited resources.

I am not suggesting that. I am rather thinking of something along the lines of how one installs e.g. openSUSE with options:

  • Plasma
  • XFCE
  • Other graphical desktop …
    (or options for e.g. Developer work, Office work - proper package sets, etc)
    …
  • Base minimal system (text console only)

If one is free to choose whatever one wants (package by package in advanced mode, considering dependencies) and can always add/remove later.

I wonder if a similar approach is possible in regards of dom0 itself. Currently, in Qubes OS we don’t have much granularity of choice. For dom0 it is all or nothing.

That’s why your efforts are appreciated,

What efforts exactly? The GitHub issue got simply closed, i.e. nobody is even planning to consider what I suggested. What good be such effort if nobody is interested? I would be happy to help if I know (and can do) what is actually necessary.

Are you a developer? I haven’t done any serious coding for many many years. The only programming I have done during the last decade has been a little PHP/JS/bash. If you can describe the procedure or give an example of what is necessary, I could probably look into it.

Take a look at […]

I am not sure I understand. You say Xen, but we are discussing dom0 here. Could you please clarify?

Regarding dom0 in particular, I have not seen any actual info about why exactly Fedora was chosen (I am not saying it is a bad choice). The “we have to trust something” is OK regarding “we need something”, but it is not an explanation why any other Linux distro (or e.g. OpenBSD or other) was not picked.

Of course I believe that approaching stateless is better than not.

What is “approaching stateless”?

There are just too many things that have higher priorities than switching distro in dom0. I think.

By “the above” I meant the somewhat misleading explanation given all around - that something which is not connected to the network is safe by design. This is a fallacy.

Also, the question here is not necessarily switching the distro of dom0. It is rather about improving the security of the almighty dom0 by minimizing it (using whatever approach may be suitable). For a security focused OS, isn’t that top priority?

BTW, I read that in Xen it is possible to have a system without dom0 at all. I wonder how that works and if it is applicable to Qubes OS. Do you know anything about that?

25

AFAIK one of the reasons is that Fedora has more frequent new releases, which allows to support relatively newer hardware by dom0.

2 Likes
26

Post can’t be empty

1 Like
27

Strange. Normally, secure systems are not aimed at “the latest and greatest” but rather at stability.

I wonder what the rest of the reasons are.

28

My impression is that Fedora is what the developer(s) were most familiar with when the project started and as discussed above there was no tangible benefit in changing it later.

There also seem to be some benefits of the RPM package system related to verification. Not sure / not an expert.

This isn’t documented anywhere, just a guess based on reading the mailing list and forum for 7+ years.

1 Like
29

Qubes is a whole new OS, which already creates a huge obstacle for entry. If you also would force people to buy exclusive hardware, then practically nobody would use it. Fedora includes a lot of important, new firmware and allows many people to “simply” install Qubes on their hardware. Qubes is not a “perfectly secure” OS, it’s a reasonably secure OS. Security without a possibility to use the system doesn’t work.

30

I absolutely agree with the OP, but perfectly understand whole discussion.

My contribution would be to sum up and rephrase whole lotta words here, to check if I understand it properly:

Is it possible devs to provide some kind of dom0-minimal flavor at the point of installation, just as they provide templates-minimal later?

31

That seems moot if dom0 is five or six versions behind.

1 Like
32

@SteveC @augsch Just imagine that dom0 would be based on Debian. Then, on the release of any new Qubes version, you would already have outdated hardware support, much older than the one with Fedora.

33

@fsflover

Nobody is suggesting anything like limiting supported hardware. Minimizing is not just about firmware only. The firmware in particular could go into separate HVMs (like sys-gui and the like). It is possible to have it like this:

  1. Detect hardware
  2. Install only the necessary components for it
  3. Offer options for installing additional components for other (e.g. removable) hardware
  4. Have 3 available at any time.

However, if certain dom0 software (qvm-* tools) creates dependency chains resulting in things like LibRaw being “necessary” in it, then this is far more complicated. This doesn’t seem distro related at all. FWIW, I found this:

https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

Qubes is not a “perfectly secure” OS, it’s a reasonably secure OS. Security without a possibility to use the system doesn’t work.

I am quite confident the phrase reasonably secure was used for reasons different from having popularity as a goal :wink:

@tempmail

Is it possible devs to provide some kind of dom0-minimal flavor at the point of installation, just as they provide templates-minimal later?

Even if it is, they are not going to do it until there is a working sys-gui:

34

Well, that’s pretty it. What I have learned for 10 years following Qubes is that devs never allowed to be forced to do anything they don’t find reasonable at the moment, but also I blindly trust their judgment on strategics.

3 Likes
35

Just as a follow up, ironically to the OP. Last dom0 update included firmware not existed so far, as it seems:

Updating dom0

local:
    ----------
    amd-gpu-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
            1:20230625-148.fc32
    amd-ucode-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
    atheros-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
    brcmfmac-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
    intel-gpu-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
            1:20230625-148.fc32
    linux-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
            1:20230625-148.fc32
    linux-firmware-whence:
        ----------
        new:
            1:20231111-1.fc32
        old:
            1:20230625-148.fc32
    microcode_ctl:
        ----------
        new:
            3:2.1-56.qubes1.fc32
        old:
            3:2.1-55.qubes1.fc32
    mt7xxx-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
    nvidia-gpu-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
            1:20230625-148.fc32
    realtek-firmware:
        ----------
        new:
            1:20231111-1.fc32
        old:
36

Is QubesOS more or less secure, given the attack surface in dom0, than GrapheneOS? A supply chain attack is certainly possible with the Fedora distribution and there have been documented links between, ahem, certain organizations and this distro RHEL/Fedora.

37

Is QubesOS more or less secure, given the attack surface in dom0, than GrapheneOS?

Discussed here.

and there have been documented links between, ahem,
certain organizations and this distro RHEL/Fedora.

Could you elaborate?

1 Like
38

That discussion puzzles me.

Qubes is for AMD64 laptops and desktops.

GrapheneOS is for Android hardware.

Qubes is tighter than Linux.

GrapheneOS is tighter than the factory Android install.

If you know what you’re doing with a Qubes box, both in terms of adversary resistant computing and networking, the OS is, as the tag line suggests, “reasonably secure”.

The device running GrapheneOS has a proprietary baseband chip - a largely undocumented coprocessor with the run of the system. That processor has a GPS receiver and turning off location services for your apps does NOT disable it. If you want to interact with others you’ll likely need to load proprietary binary blobs. And it goes downhill from there.

Graphene has another disability - it favors phones that are typically only available with post paid carrier plans. Getting to the point of a device that’s reasonably secure AND a plan that’s reasonably secure ranges from non-trivial to downright impossible, depending on the jurisdiction.

As for the main thrust of this thread, minimizing dom0, OP should describe a scenario whereby an unused binary blob in dom0 is used in a compromise. My take is that by the time an intruder gets to that you are sitting in a jail cell and someone is messing with your machine after having taking a forensic copy of the storage.

This is a “cosmic ray neutron flux on the surface of Mars” problem. That will kill you … but how were you planning on getting there in the first place?

3 Likes
39

This thread is not about Graphene OS.

As for the main thrust of this thread, minimizing dom0, OP should describe a scenario whereby an unused binary blob in dom0 is used in a compromise.

There are multiple ways to answer that:

  1. Describe what security goal justifies to install/keep/update things which will never be used.

  2. Ask creators of minimal templates to describe why they have smaller attack surface. Then ask why dom0 is not minimal too.

  3. Ask why a system that has compartmentalization as its core security principle puts so many things in its most privileged compartment.

  4. Removing non-free firmware has actually been considered and done for Debian in the past.

  5. Ask yourself what a binary blob is and how you know whether it is used or not, as well as what control you have on that.

  6. Ask what is the chance of some “bug” by a 3-letter agency actually using malicious functionality hidden in a binary blob for which it took care to .

Here is also the requested scenario:

Company X manufactures some hardware which you don’t have. The firmware required for it is proprietary. A 3-letter organization ABC tells X to put certain malicious code in the blob, thus making it hidden, and gags X. Then, the “good guys” from ABC submit an “innocent bug” somewhere which uses this functionality - not for making the hardware work but for activating that other functionality (running on your CPU). That gets complied, signed by Fedora and propagates to your dom0. You update, you are happy that you have your latest and greatest security fixes, and continue your daily work. A few months later you read news (or not) about the “innocent bug” being noticed and “safely fixed”. Meanwhile, ABC did everything it wanted, also with companies Y, Z, etc.

Now, compare this to the case in which you don’t have that blob installed at all and evaluate which is more secure.

1 Like
40

How does the binary blob get activated?

That’s the issue.

Unless you’re bored and reckless and chmod 755 heckin’ everything to see if it’s actually a working application?

The vector you describe, something getting slipped into a binary update, IS entirely possible. But unless something happens in dom0 to activate it, where’s the hazard?

Removing unused stuff is always a good move, but there are only just so many hands/eyes on this project. What you suggest is nation state grade attention, a Stuxnet sort of move. Qubes just has to be reasonably secure, and for every user that might encounter such a thing there are literal legions worried about much less theoretical problems.

This seems a very fringe sort of concern to me. Have there been any verified incidents where things like this happened to Qubes? We periodically see reports about such things with Pegasus and the like, presumably given the paranoid, reactive, skilled nature of the typical Qubes user, if it was a problem, someone should have a battle trophy that got reported.