It’s really strange that this thread kind of caused more arguments against, rather than looking into solutions.
I don’t know what solution you expect people to come up with, if you want to minimize dom0, you can just make a shellscript that removes the packages you don’t want.
1 Like
For a start, I was hoping to have the 3 initial question answered, then perhaps proceed from there.
Installing gigabytes of extra stuff, then removing it through shell scripts, is hardly a security minded approach. So, I am starting with finding the reasons for the situation, then considering next steps, rather than overestimating my skills and starting to fix a whole OS by myself.
1 Like
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)
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
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
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?
AFAIK one of the reasons is that Fedora has more frequent new releases, which allows to support relatively newer hardware by dom0.
2 Likes
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.
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
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.
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?
That seems moot if dom0 is five or six versions behind.
1 Like
@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.
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:
- Detect hardware
- Install only the necessary components for it
- Offer options for installing additional components for other (e.g. removable) hardware
- 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 
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:
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
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:
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.