search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
534 stars 46 forks source link

volatile volume of DispVM may land in a different pool than its template #5933

Closed 3hhh closed 4 years ago

3hhh commented 4 years ago

Qubes OS version 4.0 current-testing

Affected component(s) or functionality qvm-create

Brief summary Disposable VM's volatile volumes are created on the pool of their root parent, not on the pool of their direct parent.

To Reproduce

qvm-pool -o dir_path=/mnt/foo -a foo file
qvm-create -l red tvm -P foo
qvm-prefs tvm template_for_dispvms True
qvm-volume | grep tvm (all good, only root comes from the default template)
qvm-run --dispvm tvm xterm
#assuming disp9487 was created:
qvm-volume|grep disp9487

Expected behavior

foo:appvms/disp9487/private                          disp9487           private      No
linux-kernel:4.19.125-1                              disp9487           kernel       No
varlibqubes:appvms/disp9487/root                     disp9487           root         No
foo:appvms/disp9487/volatile                 disp9487           volatile     No

(volatile is on the foo pool)

Actual behavior

foo:appvms/disp9487/private                          disp9487           private      No
linux-kernel:4.19.125-1                              disp9487           kernel       No
varlibqubes:appvms/disp9487/root                     disp9487           root         No
varlibqubes:appvms/disp9487/volatile                 disp9487           volatile     No

(volatile is on the default pool)

Additional context This was originally reported at https://github.com/QubesOS/qubes-issues/issues/904#issuecomment-508295453

Relevant documentation you've consulted man qvm-pool claims that " -P POOL Pool to use for the new domain. All volumes besides snapshots volumes are imported in to the specified POOL. THIS IS WHAT YOU WANT TO USE NORMALLY " Apparently this is not always true.

@marmarek said that --pool volatile= may work in https://github.com/QubesOS/qubes-issues/issues/1527#issuecomment-500252390 but the -P behaviour is unexpected and not according to doc anyway.

Related, non-duplicate issues https://github.com/QubesOS/qubes-issues/issues/904#issuecomment-508295453 https://github.com/QubesOS/qubes-issues/issues/1527#issuecomment-500252390

3hhh commented 4 years ago

besides snapshots is also not entirely true as at least the private snapshots should always go to the foo pool.

brendanhoar commented 4 years ago

Ran into this a while back. Think it has to do with there being no config for the volatile pool in the disposable VM on creation, so it falls back on global preferences.

My hacky workaround (in personal scripts) has been to temporarily change the global pool defaults before disposable VM startup, then switch it back, which is just ugh.

I’m sure there have been a lot of users starting VMs out of secondary “more secure” pools not realizing data was being leaked to their “less secure” primary pool.

B

marmarek commented 4 years ago

This is because -P switch applies only to the VM you create. tvm has volatile volume created in the pool pointed there. But DisposableVM out of it is created separately (implicitly with qvm-run --dispvm here), and -P is not set at that time. This is similar to normal template-based VM:

  1. qvm-create -C TemplateVM -P pool-name template-name - create template with volumes in pool-name (in this case all of them)
  2. qvm-create -t template-name appvm-name - create volumes in default pool (with exception to root, which needs to be in the same pool as template)

I agree this is confusing behavior in case of DispVM specifically, as one would expect many more setting copied from DisposableVM Template, than in normal AppVM case.

brendanhoar commented 4 years ago

I agree this is confusing behavior in case of DispVM specifically, as one would expect many more setting copied from DisposableVM Template, than in normal AppVM case

In particular, if a user has a disposable VM template housed in a secondary pool and starts a disposable VM based on it, the user will be very surprised to discover that some data from that disposable VM is written to the primary pool.

andrewdavidwong commented 4 years ago

Pardon my ignorance, but why would there be any security implications here? I was under the impression that qube-level compartmentalization is at some level of abstraction above storage pools. In other words, qubes (including DisposableVMs), shouldn't "know" or "care" which underlying storage pools they're using, right?

marmarek commented 4 years ago

This is related to anti-forensics. You may want to configure your system so that some sensitive data lives entirely in a separate storage pool (perhaps separate disk you connect only for those cases). It should be also possible to configure DisposableVMs this way by adjusting appropriate DisposableVM Template. Currently it isn't possible for DisposableVMs created other than with qvm-create (aka named DisposableVM) - for example by starting an app from the "Disposable: ..." menu, or qvm-run --dispvm or even qvm-open-in-dvm - those will use always default storage pool for volatile volume.

andrewdavidwong commented 4 years ago

Thanks for the explanation! That makes sense. However, I'd think that all the data would be encrypted on disk anyway. Are there use cases in which it wouldn't be or in which that wouldn't be sufficient?

marmarek commented 4 years ago

Yes, see https://github.com/QubesOS/qubes-issues/issues/904. TL;DR: it's for the cases when the attacker gets access to unencrypted disk (for example by forcing you to reveal the key, or taking your laptop when it's unlocked).

qubesos-bot commented 4 years ago

Automated announcement from builder-github

The package qubes-core-dom0-4.1.14-1.fc32 has been pushed to the r4.1 testing repository for dom0. To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

qubesos-bot commented 3 years ago

Automated announcement from builder-github

The package qubes-core-dom0-4.0.53-1.fc25 has been pushed to the r4.0 testing repository for dom0. To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

qubesos-bot commented 3 years ago

Automated announcement from builder-github

The package qubes-core-dom0-4.0.55-1.fc25 has been pushed to the r4.0 stable repository for dom0. To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

brendanhoar commented 3 years ago

Thanks y’all, I think I can now take out a somewhat gnarly temporary change of default pool in some of my scripts! :)