Make disposable root volumes inherit read-only status from their disposable templates

[DemiMarie]

The problem you're addressing (if any)

Currently, root volumes are read-write by default, even though the writes are thrown away after the qube is shut down. However, the data written is not encrypted with an ephemeral key, so sensitive information could persist indefinitely after it should have been deleted. QubesOS/qubes-core-admin#396 will encrypt all volatile volumes by default, but root volumes need to be read-only for maximum benefit.

Describe the solution you'd like

Root volumes should be read-only. This will cause the AppVMs to set up a dm-snapshot device that allows them to be written to, which will write the changes to the private volume. When the AppVM is shut down, the volatile volume will be securely deleted by deleting the encryption key.

Where is the value to a user, and who might that user be?

All users will benefit from improved security.

Describe alternatives you've considered

We could do something similar in dom0, but that is extra complexity.

Additional context

Relevant documentation you've consulted

Related, non-duplicate issues

4408

[ghost]

To clarify applications running in that AppVM could still from their point of view have write access to /, correct?

As mentioned https://github.com/QubesOS/qubes-issues/issues/1293#issuecomment-845296329 doesn't the same thing need to happen for DispVM's home volume?

[DemiMarie]

To clarify applications running in that AppVM could still from their point of view have write access to /, correct?

As mentioned #1293 (comment) doesn't the same thing need to happen for DispVM's home volume?

Yes and yes. The latter will require additional support from within the DispVM.

[marmarek]

Where is the value to a user, and who might that user be?

All users will benefit from improved security.

No, it makes sense only for encrypted volatile volume. And that makes sense only for rather niche threat model. For everybody else, implementing this will regress performance and likely disk usage.

[andrewdavidwong]

No, it makes sense only for encrypted volatile volume. And that makes sense only for rather niche threat model. For everybody else, implementing this will regress performance and likely disk usage.

Does this mean that this is a "won't do" or that the request should be amended to change "by default" to "optionally"?

[marmarek]

The initial proposal assumed the volatile encryption was enabled by default, which was later reverted. The root volume can be switched read-only by the user already (qvm-volume config foo:root rw 0), but it's only on the VM level, we don't have global knob for that. It might make sense to tie the default to having volatile volume encrypted, but on the other hand, there may be some problematic corner cases that would be broken by such change (encrypted volatile volume for Windows maybe?).

One thing that would make sense, is the read-only root be inherited by DispVMs from their disposable template, which I think isn't the case right now.

[andrewdavidwong]

The initial proposal assumed the volatile encryption was enabled by default, which was later reverted. The root volume can be switched read-only by the user already (qvm-volume config foo:root rw 0), but it's only on the VM level, we don't have global knob for that. It might make sense to tie the default to having volatile volume encrypted, but on the other hand, there may be some problematic corner cases that would be broken by such change (encrypted volatile volume for Windows maybe?).

One thing that would make sense, is the read-only root be inherited by DispVMs from their disposable template, which I think isn't the case right now.

Sounds like the last part is the only thing you're confident would be a suitable enhancement right now, so I've reduced the scope of this issue down to just that. Other stuff can be opened as separate issues in the future.