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

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

[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"?

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

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

[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

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

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

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