I would like the ability to freeze/unfreeze dom0 state. I can imagine toggling read-only file permissions would be the way to do it.
My questions for the pros:
Can dom0 function in the read-only state launching, shutting down Qubes without unintended consequences?
How to best reset the file permissions state before locking down to read-only?
I believe Qubes has a file permissions reset script. Where do I find the script? Does it cover all the files/folders in Qubes?
At the very least the logging area(s) would need to remain writeable. And dom0 actually stores the virtual machines, too–you probably don’t want to lock that down either.
Beyond that, I don’t know.
But it’s an interesting thought!
At first I was about to compare this to (what I’ve heard about) tails, but tails lets you make changes, it just throws them away on a shutdown (sort of like a named disposable). This would be like running off a finalized CD-ROM. But again we’d have to be selective what to block. (Oh, one more: you still need to be able to delete and create VMs.)
And (you did say this, I’m just emphasizing it) it needs to be disable-able for times when one is actually trying to do things in dom0 (like writing salt states). Which for me seems to be a lot of the time (I wonder, sometimes, why I don’t just work as root since I’m constantly having to reissue failed commands with sudo in front of them).
Related issue:
Logging doesn’t seem operationally dependent? Dom0 should be able to function without logging?
And for qubes… they are stored in a common directory. If that, and only that directory was read/writable, would dom0 function in read-only state?
If I knew how to reset dom0 back to its pre-freeze state I’d run some experiments… but without a throw-away machine to experiment on, I can’t risk messing up the whole system right now.
What would be a great feature is some kind of revert dom0 to a prior state option. Kinda like the evil OSX Time Machine, or the evil Windows restore points option.
Anyone else ran similar experiments?
I’ve not tried it with Qubes, but remounting the root file system as read-only normally doesn’t work, unless the system is designed to be run like that. You are going to have software that expect to be able to write to the file system, and they can’t run without being configured to run as read-only, which isn’t always possible.
You are probably going to need a writable virtual file system, similar to disposable qubes, or a witeable layer in memory.
When do you want to toggle Freeze/Unfreeze? Runtime or Reboot (similar to Tails)?
Maybe ZFS or BTRFS as filesystem?
If your system resides on an SSD that is Opal 2.0 compliant and your /var is in a separate partition then you could define a “range” that covers the main Dom0 partition’s ssd sectors then using a password you can change that range to read-only status and back whenever needed.
One really odd use case here. You can even change an opal range to write-only status, so at least in theory as the data fills up a log partition you can hide the contents of those files from being read by any malware/spyware. You just extend that range as the data fills it.
The command line tool needed to do any of this is sedutil (sedutil-cli). So, even if you don’t choose to use SED hardware encryption, changing the range rw status should be possible. I always wanted to experiment with making the /boot partition read-only and only set it to read-write when updating Dom0. That would be a hardware enforced anti-evil-maid in the sense that nobody could change the bootstrap routines or code unless the system was running and supplied the proper password.
food for thought.
I admit I’m far from an expert regarding Qubes, but some time ago I tried deleting the contents of /var/log to free some space for the Kali template, and it resulted in an unusable system (I also opened a thread on this forum to try and fix it). Therefore I might be wrong, but I guess logging is somehow mission-critical
EDIT: The thread I was talking about: "Accidentally" deleted /var/log