On 4/6/21 7:30 AM, Artificial Amateur wrote:
Hello,
I was reading through the source code (qubes-core-admin and
qubes-core-admin-client) in an effort to help Issue #1293. The goal I
had in mind was to encrypt the private and volatile volumes of every new
AppVM and private, volatile, and root for every StandaloneVM. I'd reason
that DisposableVMs is more suited #904 than encrypted disks and
TemplateVMs have no real reason to be encrypted.

If I were to go about to implement this, how can I determine the VM
class within the Storage drivers when the disks/files are being created
(and presumably where I'd encrypt them)? Should the VM class pass from
_vm_create() to create_on_disk() to create() or is there a way to
determine based on the storage volume properties?

Would encryption best be under its own storage driver or incorporated
into an existing one?

See [1].

What does the new callback proxy driver add in functionality?

It provides a means for simple prototyping, adding code to existing storage 
pool drivers or running your own custom storage pool driver as you only have to 
implement some callback functions in a language of your choice rather than an 
entire storage pool class in Python.

As an example it includes ephemeral private.img and volatile.img encryption 
with the file pool driver [2].
You could also run your own steganography application or hidden luks volumes or 
whatever.

It however isn't an idiot-proof "I check this box there for encryption" 
solution that people in #904 and #1293 appear to expect. You'd e.g. still have to 
implement storage backend encryption for LVM pools as some bash script or so. 
File-reflink might work similar to the example implementation for the file pool driver 
[3].
I am somewhat reluctant to provide this as I don't use it myself and people never stop complaining about some missing feature anyway (this doesn't exclude myself).

Demi appears to be working on a different approach (change the storage 
interface) though as well [4]. This might be more readily accessible for users.

In total I'm not sure whether it would make sense for you to also get engaged 
into this one, but who knows - maybe you have the best idea of all? ;-)

[1] 
https://github.com/QubesOS/qubes-core-admin/pull/396#pullrequestreview-616977674
[2] 
https://github.com/QubesOS/qubes-core-admin/blob/a7fe59449a44be96004bb5825abe9ad88b33db7b/qubes/storage/callback.py#L135
[3] 
https://github.com/QubesOS/qubes-core-admin/blob/a7fe59449a44be96004bb5825abe9ad88b33db7b/qubes/storage/callback.json.example
[4] https://github.com/QubesOS/qubes-core-admin/pull/396

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/2510717f-d2b3-3fd6-bc1e-0e1b00571c53%40hackingthe.net.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to