Hi there, everybody knows how much hard work it takes to maintain a project like this. Qubes OS is a great project and I know about the downsides of FOSS.
However, I noticed that dom0 is still running on fedora-24, vm-templates upgrades to debian-12 or fedora-34 have to be done by hand and it looks like some qvm-tools depend on python2, which is one piece of old software.
So, I wish to ask, if using outdated and unmaintained software can live up to the standards you want to achieve?
Using read-only filesystems, XEN-virtualisation and iptables to seperate domains seem to me as a very good approach to build a reasonable secure operating system. Actually a perfect setup for people who work with VMs a lot.
Still, it looks to me, the project is dying. An honest feedback would be useful for the Qubes-OS user base. Maybe for the Qubes-OS maintainer and community, also.
dom0 is not exposed to the internet and there is no direct way to transfer files into dom0 from any VM. qubes-specific utilities in dom0 are regularly updated.
vm-templates upgrades to debian-12 or fedora-34 have to be done by hand
qubes packages debian stable, which is the version of debian supported by the debian security team. Debian-testing doesn’t have the same security support. (I don’t use fedora VMs so no idea about those).
The standard versions for VM’s on qubes 4 are fedora 33 and debian 10.
Both of them are still maintained and receives regualry updates from upstream.
Fedora 24 on dom0 is not problematic at all, because dom0 is strictly separated from any connection to and from outside.
See
and
I don’t thinks so. Updates are distributed regulary and the development is still moving torwards Qubes 4.1 (Nevertheless, it is not as fast as in other projects with hundred and thousands of developers).
I can understand that it is not obvious to a new user, why an operating system that aims for the best possible security allows itself to use an end of life Fedora release version for one of it’s most critical components (→ Dom0).
If an attacker is already able to execute code in Dom0 you are mostly screwed anyway. However: packages that are included in Dom0 and could have an effect on an attacker being able to break into Dom0 are very well maintained by the Qubes team.
Most importantly this includes packages for the Kernel and Xen. Having an older and even vulnerable version of some tool is not that bad for Dom0’s security unless you are able to feed exploits into it from outside of Dom0.
While it is a legitimate idea to propose a distribution with a much longer support cycle like RHEL-based, SUSE Leap-based, Ubuntu LTS-based or Debian Stable/Oldstable distributions as Dom0, it may also be beneficial that the only updates that Dom0 of Qubes stable will receive are packaged and maintained by the Qubes team (and not another third party).
A nice starting point for learning about how attacks against Qubes OS could have looked like, are Qubes Security Bulletins (QSB).
A good example is QSB #67: While Fedora 32 on Qubes R4.1 was not end of life at the time, Qubes R4.0’s Fedora 25 most certainly was. If you look at the updated packages, you will see, that R4.0 did receive an updated package for rpm, because it is no longer being provided by Fedora.
Of course you can look for included Fedora 25/32 packages that are known to be vulnerable. But the next big step is to exploit the vulnerability from outside of Dom0. Believe me: these things are being tried, but are exceptionally hard to achieve because of Dom0’s very isolated design.
I totally agree. Local privilege escalation isn’t needed, since every user in dom0 can sudo.
I suppose there are basically three attack vectors:
exploiting the Xen-Hypervisor (unlikely)
social engineering the user to move files into dom0, and execute one of them (or being parsed be a vulnerable package)
qvm-tools (hard to tell without an in depth investigation)
infiltration of maintainers source code
With introduction of sys-gui I expect that the attack surface of Qubes OS is further reduced. Since I’m using Qubes OS 4.0 for three or four month as a productive system now, I still hesitate to migrate to 4.1 rc1. And I’m not sure if the sys-gui plays well with my graphic card (Intel HD Graphics 620).
