Convenient untrusted storage for Qubes OS: qcrypt & qcryptd

[David Hobach]

Dear all,

Qubes OS has always provided the basic tools to accomplish encrypted
storage devices, namely qvm-block [1] and cryptsetup [2].

However the combination is neither self-explanatory nor convenient for
users who come from Operating Systems which provide "plug & play" for
most devices. This facilitates user mistakes made either manually or
with self-written software.

Thus I decided a while back to bring my self-written software to release
grade and therefore present qcrypt and qcryptd at

https://github.com/3hhh/qcrypt

qcrypt can be used to create, open or close encrypted containers from
dom0 in a way similar to cryptsetup [2] - just with added support for
the Qubes OS VM infrastructure.

qcryptd attempts to bring back the "plug & play" feeling by providing a
daemon that automatically opens or closes encrypted containers whenever
VMs are started, stopped or external devices are attached or removed.

Both are command-line tools and heavily rely on the bash library blib
[3]. qcryptd requires some configuration in the form of ini files [4].

Feel free to review the code, use it at your own disposal or provide
feedback (questions, issues @github, ...). I hope it'll be useful not
only for me alone. ;-)

My code signing key for reference: (1533 C122 5C1B 41AF C46B 33EB) EB03
A691 DB2F 0833

Best Regards
David


[1] https://www.qubes-os.org/doc/block-devices/
[2] https://gitlab.com/cryptsetup/cryptsetup/wikis/home
[3] https://github.com/3hhh/blib
[4] https://github.com/3hhh/qcrypt/blob/master/conf/examples/ex01.ini

[Chris Laprise]

On 6/20/19 2:13 AM, David Hobach wrote:
> Dear all,
>
> Qubes OS has always provided the basic tools to accomplish encrypted
> storage devices, namely qvm-block [1] and cryptsetup [2].
>
> However the combination is neither self-explanatory nor convenient for
> users who come from Operating Systems which provide "plug & play" for
> most devices. This facilitates user mistakes made either manually or
> with self-written software.
>
> Thus I decided a while back to bring my self-written software to release
> grade and therefore present qcrypt and qcryptd at
>
> https://github.com/3hhh/qcrypt
>
> qcrypt can be used to create, open or close encrypted containers from
> dom0 in a way similar to cryptsetup [2] - just with added support for
> the Qubes OS VM infrastructure.
>
> qcryptd attempts to bring back the "plug & play" feeling by providing a
> daemon that automatically opens or closes encrypted containers whenever
> VMs are started, stopped or external devices are attached or removed.
>
> Both are command-line tools and heavily rely on the bash library blib
> [3]. qcryptd requires some configuration in the form of ini files [4].
>
> Feel free to review the code, use it at your own disposal or provide
> feedback (questions, issues @github, ...). I hope it'll be useful not
> only for me alone. ;-)
>
> My code signing key for reference: (1533 C122 5C1B 41AF C46B 33EB) EB03
> A691 DB2F 0833

This could be an improvement over the scripts I use to mount backup
volumes in dom0.

One hope that popped into my mind as soon as I saw this post is for some
kind of automatic teardown to address this:

> but shutting down the mediator-vm during the attachment is likely to
leave your Qubes OS in a dreary state and will probably require you to
restart the system.

I've experienced this a number of times with my own setups. It would be
nice to have the unmounting and closing handled automatically, perhaps
with this:

https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-events.html#qubes.events.handler

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[David Hobach]

On 6/20/19 8:12 PM, Chris Laprise wrote:
> This could be an improvement over the scripts I use to mount backup
> volumes in dom0.
>
> One hope that popped into my mind as soon as I saw this post is for some
> kind of automatic teardown to address this:
>
> > but shutting down the mediator-vm during the attachment is likely to
> leave your Qubes OS in a dreary state and will probably require you to
> restart the system.
>
> I've experienced this a number of times with my own setups. It would be
> nice to have the unmounting and closing handled automatically, perhaps
> with this:
>
> https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-events.html#qubes.events.handler

qcryptd is listening to the Qubes OS internal events and
starting/stopping VMs & opening/closing chains accordingly. There is
currently a 1s heartbeat to implement delays, but no polling. blib
provides the underlying functionality [1].

From my experience with a chain such as
source --> mediator --> dest
shutting down the mediator may "confuse" Qubes OS/the internal qubesd
state. You should receive a warning by qcryptd though (I didn't want to
automatically shut down dest as the user might be working on unrelated
parts of the file system).

Even shutting down dest and then attempting to properly close the
remaining parts of the chain tends to trigger bug #4784 [2] and require
the aforementioned system restart. Simply shutting down the mediator
doesn't trigger the bug; that's why qcryptd does just that.

Overall qcrypt & qcryptd shouldn't trigger the bug anymore as long as
the user doesn't do anything "wild".

[1] https://github.com/3hhh/blib/blob/master/util/qubes/qwatch
[2] https://github.com/QubesOS/qubes-issues/issues/4784