QubesOS has an advantage because it uses isolation of drivers into different VMs, that’s the primary advantage, is isolation and compartmentalization, only there is no sys-disk VM. Disk read/write and encryption are a key part of a system’s security.
The other thing is, dom0 is a highly privileged VM, we need clarity into the updates that are making it into the fedora 32 inside dom0 (which is obviously EOL, so the updates have to be applied manually).
The last part is, RHEL/Fedora is not the ideal choice for a dom0 distro because of its well documented linkes to three letter agencies.
I just got hung up on the phrase “Xen’s Linux kernel” because it sounded to me like you were saying that Xen contained Linux, rather than launching Linux as a secondary step. Though it does sound like I misunderstood the extent to which dom0 was involved in running Xen’s infrastructure.
There should be an isolated VM for the disk (sys-disk)
You cannot boot a host OS without direct disk access. Even if it was magically possible, such isolation adds no security benefits. What will it protect and from what?
There should be an isolated VM for the disk (sys-disk) and also audio drivers (sys-audio) so that
you can get some isolation for the disk and audio drivers.
This talks about isolating the driver (the entity handling low-level communication with the hardware, e.g. SATA or NVMe) from dom0. Domains like sys-audio and sys-gui aim to decouple hardware from dom0 to reduce the attack surface of the host.
allow me to rephrase; the splt-dmcrypt shell script, where the encryption API is isolated, would be a better approach.
That is a different thing. AFAICS, qubes-split-dm-crypt aims to isolate the decryption mechanism (not the hardware) from a potentially malicious destination VM (not dom0) for the purpose of improving encryption key confidentiality. There is no point to hide secrets from dom0.
Moderation note: @janglingquo_575 unless you’re willing to back your claims with facts, abstain from incendiary statements like this in the future. FUD is not welcome in this forum.
A link to a three-letter agency doesn’t have to imply a danger in case of free software. Otherwise you should not use Tor as well.
This decision was reverted later.
There is a related discussion here about Debian. In it, I tried to use the same argument about the proprietary blobs, but didn’t convince anybody. Surprisingly, even @marmarekdoesn’t see any danger in it. Perhaps it’s a small danger, less important than many other attack vectors on Qubes, but I fail to see why it should be completely denied.
After upgrading to 4.2.0, I notice that individual firmware packages are no longer dependent on each other (although linux-firmware is not granular at all), so uninstalling some of them works.
However, the qubes-dist-upgrade installed 45 new packages as “weak dependencies” (not required by any other package), among which:
cpp (is anyone compiling code in dom0? no package requires that)
hunspell-en (is anyone supposed to spell check in dom0?)
exiv2 (is anyone supposed to manage image metadata in dom0?)
nano-default-editor (considering we already have vim?)
ntfs-3g-system-compression (who uses ntfs in dom0 at all?)
pinenentry (not required by any package at all, according torepoquery -q --installed --whatrequires pinentry)
tracker-miners
etc.
Additionally, curl got installed because rpm-0:4.18.2-1.fc37.x86_64 requires it.
IMO, this is moving from bad to worse and goes against all the talk about minimalism as a security measure.
Running dnf autoremove in dom0 shows 100 packages (323M).
From man dnf:
dnf [options] autoremove
Removes all "leaf" packages from the system that were originally installed as
dependencies of user-installed packages, but which are no longer required by
any such package.
I have been curious as to wondering if it would cause too much headache to either:
have an immutable OS like VanillaOS as Dom0
or
create a VanillaOS Template
(as an immutable OS would this mean that the Template qube can’t be broken — as in altered — since an immutable OS is its template making it therefore truly ethereal in a disposable qube Templated with VanillaOS as its base template? So then maybe Dom0 need not be altered to an even harder state if the qube is made immutable and disposable, correct or no?)