QubesOS / qubes-issues

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

DisposableVMs: support for in-RAM execution only (for anti-forensics) #904

Open marmarek opened 9 years ago

marmarek commented 9 years ago

Reported by joanna on 25 Sep 2014 20:26 UTC Currently volatile.img is being backed up on the fs. See: https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4/discussion

Migrated-From: https://wiki.qubes-os.org/ticket/904

Rudd-O commented 6 months ago

Not instantaneously, no:

[root@roxanne ~]# zfs create roxanne/unencrypted
[root@roxanne ~]# zfs snapshot roxanne/unencrypted@blah
[root@roxanne ~]# zfs clone -o encryption=on -o keyformat=passphrase roxanne/unencrypted@blah roxanne/encrypted
cannot create 'roxanne/encrypted': 'encryption' is readonly

The workaround is to use send and receive. You can send from an unencrypted snapshot to an encrypted dataset. But that is not instantaneous — it may take a while:

[root@roxanne ~]# zfs destroy roxanne/encrypted
[root@roxanne ~]# zfs send roxanne/unencrypted@blah | zfs receive -F -o encryption=on -o keyformat=passphrase -o keylocation=file:///etc/passwd roxanne/encrypted
[root@roxanne ~]# zfs get encryption roxanne/encrypted
NAME               PROPERTY    VALUE        SOURCE
roxanne/encrypted  encryption  aes-256-gcm  -

That performance hit may prove acceptable for a dvm private volume upon dvm instantiation, but I'm not sure it would be acceptable for the root volume of the dvm — that tends to be many gigabytes of data that needs rewriting from unencrypted into encrypted form.

zfs change-key is not an option (hypothetically if we were cloning from an existing encrypted dataset to a disposable dataset, to make thing go faster) because changing the password does not change the master key (as per https://openzfs.github.io/openzfs-docs/man/master/8/zfs-change-key.8.html ).

I think what we want is simply that all writes to the dvm's disks are persisted with an ephemeral encryption key, and we use the underlying storage for reads, in a sort of overlay fashion. Smells like device-mapper all over again.