How to minimize dom0?

[tempmail]

@janglingquo_575

buggy code is usually backdoored code, they are often found together.

I think you just disqualified yourself from the relevant discussion. With me, at least.

Mainly, because with

@janglingquo_575

For example, in 2018 VLC had reached end-of-life status in May of that year. In that case, Whonix users who did not utilize a different media player were at risk, because VLC in Debian jessie has unpatched security vulnerabilities.

… you just indicated that you miss Qubes OS concept totally.

Read, create opinion, make a reference then discuss. Too late for me at least.

[janglingquo_575]

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.

[skyvine]

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.

[janglingquo_575]

allow me to rephrase, the dom0 linux kernel.

[skyvine]

Note that the QubesOS development team does provide support for dom0 even after it reaches EOL upstream. Supported releases | Qubes OS

[qubist]

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?

[janglingquo_575]

allow me to rephrase; the splt-dmcrypt shell script, where the encryption API is isolated, would be a better approach.

currently there is a saltstack formula for sys-audio, but none for splitting dm-crypt API into its own VM.

It is a shell script here: GitHub - rustybird/qubes-split-dm-crypt: Isolate secondary storage dm-crypt and LUKS1 header processing to Qubes DisposableVMs

but there is no saltstack formula.

what I’m suggesting is that there be a saltstack formula for split-dm-crypt

[qubist]

Previously you said:

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.

[gonzalo-bulnes]

@janglingquo_575

I mean RHEL/Fedora are linked with (insert three letter agency here).

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.

[janglingquo_575]

So the hardware driver for read/write to/from disk still resides in dom0, but the encrypt/decrypt (dm-crypt)
package is isolated in a VM?

[qubist]

Apart from SELinux itself being developed by NSA (which does not automatically mean it is malicious but it is a link), Red Hat also confirms:

“Red Hat partners with state and local agencies to deliver value with open source solutions.”

State and Local Government | Red Hat | Digital Transformation

“Red Hat has the open source technology and expertise to partner with the DoD…”

Department of Defense | Red Hat | IT modernization and security

[janglingquo_575]

So what’s the actual benefit of isolating the encrypt/decrypt (dm-crypt) into its own VM? Does it have to do with sourcing entropy?

[janglingquo_575]

Does Qubes utilize SELinux? Can it be configured? Is there a performance hit from the additional logic?

[qubist]

That is explained on the link you shared.

[qubist]

Yes, in 4.2.
I don’t know.
A little.

[fsflover]

@janglingquo_575

Well, alpine would be a safer choice, I mean RHEL/Fedora are linked with (insert three letter agency here).

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.

@qubist

• Removing non-free firmware has actually been considered and done for Debian in the past.

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 @marmarek doesn’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.

[qubist]

I don’t see any firmware installed in debian-12-minimal.
In Fedora 37 minimal dnf list --installed | grep firm returns nothing too.

[qubist]

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.

[qubist]

New finding:

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.

[Lace]

I have been curious as to wondering if it would cause too much headache to either:

1. have an immutable OS like VanillaOS as Dom0
   or
2. 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?)