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

[3hhh]

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 #904 (comment)

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 #1527 (comment) but the -P behaviour is unexpected and not according to doc anyway.

Related, non-duplicate issues
#904 (comment)
#1527 (comment)

[3hhh]

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

[brendanhoar]

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]

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]

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]

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?