I know installing software in dom0 is strongly discouraged. However, what if you’re installing a trusted piece of software?
As far as I understand, downloading from qubes would download software from the fedora repos, and only download what you tell it too along with its dependencies.
Unless dom0 is giving complete internet access during this? Or does it just utilize a proxy and only allow you to download what you’ve specified?
So I want to install, redshift and tcl for example. I considered these two trusted, after all pretty much all Linux users use them, especially tlc for power mangement.
If qubes has a sophisticated mechanism like this that pretty much guaranteed you’re downloading what you want, why is it not recommended to install into dom0?
You have to trust that piece of software: yes, it may be signed and its signature verified, but you still have to fully trust that it doesn’t contain any backdoor. Assuming that you’ve review the code and that you fully understand it, then this point shouldn’t pertain to you.
By installing more software, you increase the attack surface that can potentially be exploited by an attacker.
That’s why, for example, minimal templates are preferred for VMs if correctly configured, because they limit the available attack surface by running less code.
For your second point, dom0 would remain offline after installing so wouldn’t it be isolated unless it’s specifically designed to attack qubes? I feel like tlp and other well know software is probably ok in terms of back doors
If you trust it not to enable networking, you should be fine if all you care about are remote attacks. If your threat model includes local attacks, you may still be increasing the available surface.
Because that’s not the only risk. The dom0 secure update mechanism protects against an adversary manipulating your package when you try to download and install it, but it can’t do anything to protect against a validly-signed package that was already malicious or vulnerable when it was uploaded to a trusted repo, for example.
Being offline doesn’t prevent a computer from being compromised.
What would be doing the monitoring, and where? Dom0 is the most trusted VM in the system. If dom0 is compromised, then dom0 can’t be trusted to monitor itself and report its state honestly to you. You could try to run the monitoring from a different VM, but since dom0 has ultimate control over the system, it could manipulate the monitoring VM and you again wouldn’t be able to trust that VM to report dom0’s state honestly to you.
Right, thanks for that. So what you’re saying is the dom0 update mechanism is safe, but you can’t guarantee the safety of the software you’re downloading, even if it’s signe and open source?
In principle, nothing should change in dom0 at all, except when it’s updated. If it was not updated and no files were changed in it (which could be confirmed by the coreboot), then it likely did not go online. This is because by default it’s not going online.
Consider an analogy: Can you guarantee the safety of a bottle of water or a can of food, even if it’s sealed, doesn’t show any signs of tampering, and hasn’t passed its expiration date? No, of course not. It’s always possible that there was some mistake before the packaging step that made it unsafe for consumption, and this does happen from time to time. And yet, billions of people trust such products with their lives every day.
Software is made by people. People make mistakes. In software, mistakes are often called “bugs.” When bugs affect security, we call them “security vulnerabilities.” We can’t guarantee the absence of security vulnerabilities for the simple reason that we can’t guarantee the absence of mistakes. Any software you install could have a security vulnerability in it, even if it’s signed and open-source, and the more complex that software is, the more likely this is.
In fact, that’s exactly why Qubes was invented. The creators realized that trying to prevent or fix all security vulnerabilities is hopeless, since the software developers of the world are churning out buggy code far faster than anyone could ever hope to patch it. Instead, the Qubes creators realized that it makes more sense to compartmentalize all the buggy software so that when security vulnerabilities inevitably do get exploited, the damage is limited, and a single cyberattack doesn’t take down your entire digital life in one fell swoop.
I think some local files do change in the course of normal use, such as domU data, internal Qubes databases, dom0 config files, and so on. But perhaps all other files besides these shouldn’t change except during updates.
