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).
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.
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.
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.
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