Feature suggestion: optionally immutable /home

[na--]

a.k.a. "reimplement /home persistence with bind-dirs"

General notes:

There are many possible reasons for wanting an immutable (i.e. the same as in the template and not persisted across reboots) /home folder. In my case I want my dotfiles and application settings to be the same and up-to-date for every AppVM based on the template.

I persist only the specific files I want by symlinking certain folders in the template /home folder to /rw/home (ex. ~/.gnupg -> /rw/home/.gnupg, .mozilla, .ssh, .bash_history, etc.), but bind-dirs for subfolders of /home can also be used as a finer-grained persistence than the current one. I understand that maybe that's a bit much for most users, but implementing the persistence of /home via bind-dirs allows everyone to choose what they want: fully persistent like it is now, only certain folders or no persistence at all.

In my case I've commented out those lines in the template after making sure that the template /home is properly initialized (I replaced them with initialize_home "/home" ifneeded for a single boot in the template) and that's all it took.

Related issues:

None that I could find

[adrelanos]

https://github.com/tasket/Qubes-VM-hardening ?

//cc @tasket

[na--]

@adrelanos: it looks like my approach and this overlap somewhat, but can also be complementary. I think that with my approach, by changing a few lines in mount-dirs.sh and adding a default bind-dir config in the templates, most users won't know that anything has changed (/home will be persisted exactly as it currently is), while advanced users can fine-tune or disable the persistence and can also more easily implement hardening features like the one you linked.

[tasket]

Hi @na-- Not sure if I follow.... You are preventing the regular bind-mount of /rw/home onto /home, and then adding /home to bind-dirs? So the result is wherever you have symlinked from /home/* to /rw/home/* those files persist?

On the definition of "persist" here: Usually that is meant to convey "retains changes by runtime process". Do you mean that, or the opposite meaning "retains original content"?

[na--]

By persistence I mean that when files are changed in an AppVM and the AppVM is restarted, the changes are still there. Ignore the symlinks for the moment, I shouldn't have mentioned my specific workflow to muddle the waters. Let me try to explain again what I mean.

By default in QubesOS AppVMs only changes in the /home folder are persisted across restarts. Optionally, users can also use bind-dirs to persist other files and folders across VM restarts. My problem is that the persistence of the /home folder is not optional, it's hardcoded and you cannot opt out of it or disable it without changing a script from a default QubesOS package, thus making future updates of said package more difficult. If we implement the persistence of /home via bind-dirs configuration instead of it being hardcoded, we will get exactly the same functionality as we have now (normal users won't notice anything has changed), but it will be more flexible and better for advanced users and hardening the system.

[tasket]

Thanks for the explanation. I think I also understand the symlink aspect now: The template /home is in the root fs and links in there pointing to /rw/home allow persistence. If that is so, then the template itself may be affected by any appVM data/configs brought into the template's /home.

That's one effective difference with Qubes-VM-hardening: Files stored in the template are located in a special path that isn't used by other parts of the OS, so in a running template VM the files remain inert and their presence there is low-risk.

I have wondered myself why /home wasn't put into bind-dirs, though. Probably because its Unix tradition to have a separate /home volume to begin with. Its also relatively uncomplicated to reproduce the /home environment (so users don't lose access to their data) from /rw/home when all the system has to do is process fstab normally.

[na--]

Yes, in my specific scenario the template home is in the root, but it cannot be affected by any appvm data, because I don't execute anything directly in the template. The template home folder mostly has my dotfiles, some basic settings and a whole lot of broken symlinks to /rw/home, which is practically empty in the template. Different appvms fix some the the broken symlinks, for example by having .ssh with some keys in /rw/home in one AppVM or by having a .mozilla folder (thus persisting firefox settings) in another, etc. In my specific usage, nothing of /rw is ever bind-mounted with bind-dirs, but most of the same effects can be achieved via the usage of bind-dirs for specific home subfolders or the whole home folder (if I want to preserve the default qubes behaviour).

I think that bind-dirs is not used for the persistence of /home because bind-dirs was implemented relatively recently while I think that home folder persistence was always present

[tasket]

If #3704 is implemented with snapshots / boot points, it could automatically satisfy this issue as well. It would also protect the attack surface in non-home areas of /rw.

[na--]

Not really, though I'd very much like to have snapshots/boot points for sys-* VMs.

My use case here is that very often I want to have common dotfiles and configuration files across different VMs and for them to be actually be updated when the TemplateVM updates. By default, in the current QubesOS, this doesn't happen - the home folders are automatically and wholly persisted and once a VM is created its home folder lives its own separate live, never to receive updates from the template again. That was a real PITA when I wanted to update .zshrc for example, or some application conf file across all VMs I actively use. VM snapshots / boot points, while useful for system VMs that you rarely use directly, will actually exacerbate this issue for VMs that you directly use often.

[3hhh]

Actually nowadays the same applies to /usr/local (cf. QubesOS/qubes-core-agent-linux@86413df). One could move everything to /etc/qubes-bind-dirs.d/10_qubes-defaults.conf or so as default to make it removable by the user.

However IIRC the "nothing mounted"/no bind-dirs option will still remain different from disposable VMs though as the private volume is still r/w attached and mounted at /rw/ for AppVMs.

I.e. from a security point of view:
If malware wants to remain persistent, it would simply have to write itself there and possibly add itself to /rw/config/rc.local. Ironically bind-dir configurations via /rw/config/qubes-bind-dirs.d/malware.conf are another option for malware to autostart itself during VM boot.

So to obtain a "minimal state VM" for security reasons (cf. #1006) this way one would also have to move all VM-specific configuration away from /rw/ to its template or dom0 (i.e. out of reach for malware to change it) apart from just stopping to mount /home and /usr/local.

Another method that might prove more successful and somewhat works right now:
Use a disposable VM with a static name and write a small script to attach an additional persistent storage device to it during or after booting (via qvm-block). Then bind that persistent storage to whatever directory you need.
If you don't trust the storage backend, you can encrypt the whole thing. As it happens, I wrote a tool to do that a while ago.
Funnily enough I haven't used it that way yet, but I guess I might try. ;-)

[deeplow]

@andrewdavidwong if I'm reading correctly this issue is a subset of #1006.

[github-actions]

This issue has been closed as a "duplicate." This means that another issue exists that is very similar to or subsumes this one. If any useful information on this issue is not already present on the other issue, please add it in a comment on the other issue. Here are some common cases of duplicate issues:

• The other issue is closed. The other issue being closed does not prevent this issue from duplicating it. We will examine the closed issue and, if appropriate, reopen it.
• The other issue is for a different Qubes release. We usually maintain only one issue for all affected Qubes releases.
• The other issue is very old. The mere age of an issue is not, by itself, a relevant factor when determining duplicates.

By default, the newer issue will be closed in favor of the older issue. However, we make exceptions when we determine that it would be significantly more useful to keep the newer issue open instead of the older one.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "duplicate" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.