It seems dom0 is not as optimal (minimal) as it could be.
Here is an example:
root@dom0:~ # dnf list --installed *firmware* | sed -r 's/ {2,}.*//g'
Installed Packages
alsa-sof-firmware.noarch
amd-gpu-firmware.noarch
intel-gpu-firmware.noarch
linux-firmware.noarch
linux-firmware-whence.noarch
nvidia-gpu-firmware.noarch
I have no NVIDIA or AMD hardware, yet this firmware (which IIUC is certainly proprietary) is there by default (not installed by me explicitly). This is quite concerning in terms of security and doesn’t quite match the advices regarding minimizing the attack surface.
Another random example:
user@dom0:~ > rpm -qi nmap-ncat
[...]
Description :
Ncat is a feature packed networking utility which will read and
write data across a network from the command line. It uses both
TCP and UDP for communication and is designed to be a reliable
back-end tool to instantly provide network connectivity to other
applications and users. Ncat will not only work with IPv4 and IPv6
but provides the user with a virtually limitless number of potential
uses
Why would dom0, having no network functions whatsoever, need a networking utility?
LibRaw is there too. Why? Is anyone supposed to convert raw images in dom0 which is contradictory to the whole philosophy of Qubes OS?
There are also kernel-devel (ando other -devel) packages and I have no idea what dom0 uses them for, considering dom0 is not aimed to be used for development.
Etc. (I have not digged through every installed by default package)
My questions are:
Why is dom0 not minimized and includes unnecessary stuff?
How to improve that?
How can one use a different basis for dom0? (and why isn’t e.g. Debian the default one or an option)
Some of this might be a consequence of using Fedora, which I’ve noticed has some flaws in what is and is not a dependency of a package.
On the other hand, some of these firmware are required to be able to boot the system if the hardware is present. You aren’t getting very far through the boot if any modern Nvidia GPU is present but you don’t have the firmware.
Yes, I can see there is certain dependency chaining.
On the other hand, some of these firmware are required to be able to boot the system if the hardware is present.
As I wrote, it is not present and it is not going to be. Having (and updating) a ton of unused proprietary binaries doesn’t look like a security focused approach.
Someone more knowledgeable might correct me on this, but the assumption is that if “someone” is able to “reach” software in Dom0, then it’s already Game Over. Qubes OS would have already been compromised if someone was to exploit a vulnerability in NVIDIA, AMD or Ncat.
As far as I know, you’re correct. (I am not one of the real gurus here.)
I went through a phase of wishing I could send messages from one qube to another without involving dom0 at all, but then realized this is not like VirtualBox, in that the admin qube that gets to see everything is actually a full blown OS install running directly on the bare metal; instead dom0 is itself a separate VM. In other words, in VirtualBox the admin machine actually contains the virtual machines, and the admin machine is directly exposed to the internet. On Qubes, the Admin machine is separate from the others–it has a lot of privileges but it is separate. And the Admin machine is not directly exposed to the internet. Dom0, far from being the weak link that touches everything nasty in cyberspace, is cocooned. This is a much more secure architecture, so I was able to relax about letting dom0 “see” transactions between other qubes. Dom0 can see them but it’s really hard for someone on the outside to see dom0.
While knowing that remote access to dom0 is an option ready to be installed one liner far away (maybe I was wrong to read it somewhere here, or on github)? Can I imagine any compromised software to be able to invoke installing remote acces to dom0 then?
Someone more knowledgeable might correct me on this, but the assumption is that if “someone” is able to “reach” software in Dom0, then it’s already Game Over.
Well, information security is not as simple as 0 (Game Over) or 1 (perfectly safe). Any bug/vulnerability in Fedora packages installed in dom0 reaches dom0. More packages = more possibilities:
fedora-38-xfce is 5.7 GiB.
fedora-38-minimal is 2.6 GiB.
debian-12-minimal is 1.4 GiB.
dom0 is 7.2 GiB.
Qubes OS would have already been compromised if someone was to exploit a vulnerability in NVIDIA, AMD or Ncat.
Personally, I have no evidence if anyone has used IntelME, CPU vulnerabilities or proprietary firmware for actual exploits. There is evidence that these are possibilities though.
“Any local vulnerabilities in an application may become remote vulnerabilities when you execute it through Ncat.”
Please don’t get me wrong, I don’t mean to be argumentative. Just trying to avoid assumptions that things are safe just because there are no breaking news and flashing red lights all around.
That is the proper mindset, technically speaking, for security. The lack of flashing red lights means either 1) there is no problem or 2) there’s no known problem, and the attacker doesn’t know it either or 3) the attacker knows about it, is using it, and is being very careful to not have any visible effect.
And you can’t tell those cases apart…so you can’t assume it’s not #3.
You understand this, of course, so I apologize for belaboring it to you, but I want to underscore it for others who might read this thread.
I think as long as the user do not run random software in dom0, the vulnerability of “installing” something is minimal, which is why we have “templates and appvms” system. And yes, minimizing dom0 is good, and Qubes team is developing sys-audio and sys-gui-gpu to isolate even more devices (along with their open-source or proprietary drivers) from dom0.
I think as long as the user do not run random software in dom0, the vulnerability of “installing” something is minimal, which is why we have “templates and appvms” system.
I am excluding such cases here because it is impossible to protect a careless user.
Please also note that most of the packages in dom0 are installed at the time of initial OS installation and the result doesn’t look minimal. Hence the thread.
D
The user must take care of themselves. Even for an careless user, it’s unlikely that those pre-installed packages contain malicious code, given their popularity and open-source nature. And regular vulnerabilities are very different from malicious code, because exploiting a vulnerability of a random package installed in dom0 should be, by design, quite difficult.
The main principle is that we trust dom0 ultimately. The trust is created by the developers, and maintained by the user.
The ultimate trust in dom0 is not user’s choice but an inevitability. The only alternative is not to use Qubes OS at all.
Taking care of oneself includes attention to potential insecurities. That is what this thread is about. I have shared what caught my attention and it seems to me important exactly because of the inevitability.
Re. your arguments:
Proprietary firmware (included in dom0) is not open-source.
Dangerous activity does not necessary come from malware (intentionally created for mischief). It can come from bugs. There are many bugs in FOSS. There will always be. The bigger the package, the bigger the chance for them. A bug in a library function called by many other programs can damage/destroy data without anyone intending that and the user may notice that months after it happened. (I am deliberately using a strong example, for clarity)
The likeliness of malicious code in FOSS is not determined only by its popularity. Please just consider the possible attacks on repositories, the fact that distro packagers don’t check every code, the build process itself, the hardware and software on which distro packaging happens is not 100% carefully verified FOSS, etc.
exploiting a vulnerability of a random package installed in dom0 should be, by design, quite difficult.
In case you mean the design of Qubes OS, it does not protect dom0 from dom0 itself. So, it is as difficult to exploit, as any similar Fedora installation. In may actually be easier, considering the default password-less root.
“One of the biggest security concerns at the moment for Qubes is how much power is in dom0.
[…]
Even browsing relaxing landscapes as desktop wallpapers can expose dom0 to numerous vulnerabilities that intermittently appear in image-processing libraries.”
If you have answers to the initial questions, I would very much like to read them.
QubesOS includes the Linux firmware package because different people need different firmware depending on their hardware configuration, without the Linux firmware package everyone would need to supply their own firmware. It would make it much more difficult to run Qubes on laptops that need firmware for Wi-Fi and graphics.
The binary blobs don’t do anything, they are not binary x86 executables. You can delete them if you want to, but make sure you don’t delete the files needed to use your hardware.
I know that. However, it seems more correct to detect hardware during OS installation, install the firmware needed for it, then suggest an option to the user whether to install the rest (and which ones exactly) explaining the pros and cons. Then one can choose to add some (e.g. for removable devices not present during installation) or not. Would you agree?
The binary blobs don’t do anything, they are not binary x86 executables.
If you mean they don’t do anything when not called directly, that might be correct. Generally speaking though, binary blobs definitely do something. Otherwise they would not be necessary.
I understand that firmware runs on the device it is made for, not on the system CPU. However, today things are far more complex and interconnected, so I suppose this complexity would deserve a separate thread itself.
You can delete them if you want to, but make sure you don’t delete the files needed to use your hardware.
Uninstalling amd or nvidia firmware is impossible without breaking dependencies. Manually deleting files is probably futile as they will be restored with newer versions during system updates. Doing this manual “clean up” after each update does not really solve the issue with dom0 being huge because it not only wastes traffic (and perhaps SSD writes) but it also downloads software which is totally unnecessary (in case of all firmware for all possible devices) or potentially risky for dom0.
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.
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.