RFC: changes to vm private image

[john.david.r.smith]

currently an app vm (or rather non template vm)
has two images:
* root: mounted at / and is volatile
* private: mounted at /rw (subject to change) and is persistent

while using qubes i came across some features i would like (i also tried
to add an estimation about the implementation effort):

1)
feature:
add the possibilty to mark the private image as volatile in the settings
of an vm. (discard any changes on shutdown)

why:
with this feature, we could make vms immutable.
this increases security, since a corrupted vm is automatically reset.
also why should a vm have the possibility to change data/store new data
if it does not need to?

vms where i would use this feature:
* all vms based on whonix-gw (after the first start-up where i
selected whether i want to connect directly to tor)
* vpn tunnel vms after the tunnel was configured
* sys-usb
* sys net (i would change into persistent mode, if i want to add a
wlan password and want it to be stored)
* sys-firewall (has no state i know of, except custom rules to allow
intervm connections)
* a tails hvm

difficulty of implementation:
i think this should be not to hard to implement, since this volatility
is already there for root images.

2)
feature:
allow more than one private image for a vm.

why:
in combination with 1), this enables the user to restrict the vm's
persistent storage possibilities to the minimal necessary (why should
the vm be able to do more than it needs to).

example A)
a vm for browsing the internet has the following images:
(volatile) root at /
(volatile) private0 at /rw
(persistent) private1 at /home/user/.mozilla/firefox/
now we have a persistent firefox profile, but the vm can't store data
elsewhere. (with this we can reduce the areas where something can hide)

an analog example would be sys-net (the non volatile image would be
mounted to '/etc/NetworkManager/system-connections/' (where the wlan
passwords are stored)

difficulty of implementation:
should be not too hard.
hvms already support one additional disk. (but i don't know how much
will change for qubes 4)
as far as i remember the code for qubes 4, a dictionary is used for vm
images. (so i guess multiple disks could be handled)
of course we would need to decide how to handle these additional images
when cloning the vm. (i suggest simply copying them)
the possibility to select which private image to backup would be nice.
(it could reduce the backup's size)

also i think it would be nice to allow template vms to define these
additional images and mount-points (then the user could configure an
browse-internet template once and would not need to modify each
browse-internet-appvm)

3)
feature:
correctly handle sym-linked images. (it works for whole vm folders, so
why shouldn't it work for the image files directly?)

why:
my machine has a small ssd and a big hdd.
in some vms i have data i want to benefit from my ssd (e.g. program
profiles) and large amounts of data to big for my ssd (raw images/videos).
with feature 2) and 3) combined, i could have a data image stored on my
hdd and a profile image on my ssd.

difficulty of implementation:
i am not sure, but this already works for hvms and sym-linking vm
folders works.

4)
feature:
allow multiple vms to attach a the same disk (all but one must be volatile).
the data would only be "shared" when shutting the vm down.
(just like root images for templates)

why:
i could have a RAW image mounted as volatile to my image-edit vm, while
importing new images in my image-import vm.

difficulty of implementation:
this already works for root-images of template vms.

5)
feature:
allow vm images to be encrypted by dom0.
the password is entered in dom0 and all en/decryption is done in dom0.

why:
this way we can encrypt any vm without support by the os in the vm.
also the key never leaves dom0 (so a corrupted vm can't leak it).
if a vm contains sensitive data, we can simply delete it.
even an attacker who gains access to dom0 (after the vm was deleted)
would not be able to get access to the data.
i think this could be useful for people working with sensitive data
(activists et al.).

difficulty of implementation:
we already have cryptsetup in dom0, so it should be manageable.



if i had to order the features by priority: 1, 2, 5, 3, 4

so what do you think about these features?
i think they would increase security and usability.
also most of them should not be to hard to implement.

-john