Aiming to a readonly dom0

[tlaurion]

When comparing two root snapshots per

[user@dom0 ~]$ cat /lib/systemd/system-shutdown/root-autosnap 
#!/bin/sh

#This permits wyng-backup to backup root-autosnap and root-autosnap-back, taken at each system shutdowns like any other QubesOS LVMs.
#This also permits to restore to different states of dom0 from Heads and compare dom0 between reboots

#TODO: backup /boot content into a LVM and apply same logic, corresponding to each dom0 snapshots
#https://github.com/tasket/wyng-backup/issues/63

#We delete the backup of last shutdown snapshot (last last shutdown)
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap-back || true
#We take a snapshot of root-autosnap into root-autosnap-back
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root-autosnap -n root-autosnap-back
#We remove root-autosnap
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap || true
#We create root-autosnap from root
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root -n root-autosnap

And then we compare the content of the filesystems, we see that:

• /etc/libvirt/libxl
• /etc/lvm
• /etc/xdg/adjtime
• /home
• /root
• /var

Would need to be out of root fs to be able to have a RO QubesOS dom0 with dmverity

Originally posted by @tlaurion in #4371 (comment)

[andrewdavidwong]

Duplicate of #5777

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[tlaurion]

@andrewdavidwong I am not sure if those are really duplicates.
#5777 takes into consideration that sys-gui seperation was the only reason of files changing under dom0. Following posts in that thread proposed radical approach, like switching to SilverBlue instead of externalizing based on current course of action being staying on Fedora.

This issue, "aiming to a read only dom0" is an attempt to take practical steps based on current observations of what is changing across dom0 reboots today without Qubes configuration changes, in the goal of first taking notice of what is changing, and then taking steps toward that goal, as a subset of a more important goal: being able to take external measurements of dom0 to quickly measure it externally prior of boot, being a goal of pre-boot environements (Heads, safeboot, others).

This issue provides simple tool to investigate those changes (snapshots of dom0-root volume at shutdown) to ease comparisons of filesystem and file level changes toward attaining that goal through iterations.

As of the time that post was written under #4371 (comment), the following files/dirs changeed through a simple reboot without any Qubes configuration changes:

• /etc/libvirt/libxl
• /etc/lvm
• /etc/xdg/adjtime
• /home
• /root
• /var

This means that dom0-root volume's integrity cannot be sealed/verified in pre-boot environment prior to being addressed, and to address other changes and scope what changes should be considered as a tampering, otherwise being externalized.

Easier to externalize:

• A single log entree being written would invalidate dom0-root integrity) : logs should be externalized to a different volume, sent to another qubes (sys-logs)
• dom0 /root and /home should be externalized from dom0-root volume

Harder to externalize (might be ok to trigger dom0-root volume integrity invalidation):

• Addition/removal/modification(often modified, here just at reboot) of Xenstore entrees will invalidate modify dom0-root volume (/etc/libvirt/libxl)
• Addition/removal/changes(often modified, here just on reboot) on LVMs will change LVM metadir content (/etc/lvm)

---

This issue was originally reported under #4371 (comment), which was followed by @DemiMarie answer:

Personally I would be fine with moving these off of the root filesystem.

Basically @andrewdavidwong, this issue is an attempt to address the issue iteratively and track progress of that, without replacing fedora by silverblue or expecting this to just magically happen.

I can continue under #5777 if still considered a duplicate.

[andrewdavidwong]

#5777 takes into consideration that sys-gui seperation was the only reason of files changing under dom0.

The reporter's reasoning is not really that relevant, IMO. What matters more is the goal ("make dom0 read-only"), whether the devs think the goal is worth pursuing, and what the devs think is the best means for achieving that goal.

Following posts in that thread proposed radical approach, like switching to SilverBlue instead of externalizing based on current course of action being staying on Fedora.

Actually, there is only one very brief comment (aside from mine, which was also just a brief historical note), and it didn't really propose anything radical. It just said "maybe it's possible to use this thing."

Also, anyone is free to comment on posts, no matter how wrong-headed their ideas or remarks. We generally only hide or delete their comments if they're spam, off-topic, violate our code of conduct, etc. So, you shouldn't really assign any weight to random people's comments on issues, otherwise other people will also be able to devalue issues you open simply by making uninformed comments on them.

This issue, "aiming to a read only dom0" is an attempt to take practical steps based on current observations of what is changing across dom0 reboots today without Qubes configuration changes, in the goal of first taking notice of what is changing, and then taking steps toward that goal [...]
Basically @andrewdavidwong, this issue is an attempt to address the issue iteratively and track progress of that, without replacing fedora by silverblue or expecting this to just magically happen.

So, you agree that you have the same goal as #5777; you just want to take iterative steps to reach that goal. But no one on #5777 said they were opposed to taking such iterative steps. In fact, the only comment was, "Maybe it's possible to adapt fedora silverblue for that purpose." I read this as someone simply saying, "Hey, maybe this thing might be useful for you, in case you haven't heard of it." To me, it sounds like you want to pursue your own path toward the goal of making dom0 read-only, but IMO the open-source ethos instead indicates that you should seek to persuade others that your path is the better one (or at least give it a try), especially when the existing issue is very brief and general and not really opposed to yours.

In other words, I still don't see why this issue isn't a duplicate of #5777.