sys-usb needs more than default RAM to mount LUKS encrypted backup volume

[Alex]

Hi all,

In migrating multiple systems to Qubes 4.0 I noticed that sys-usb was unable to mount the LUKS encrypted hard drive that contained my Qubes backup. Looking into the logs I realised the process was getting killed by oom-killer, which is invoked when the system has ran out of memory.

Increasing the default allocated memory of sys-usb from 300MB to 500MB solved this issue.

@devs: I would recommend fixing this default value out of the box.

Many thanks,

Alex

[awokd]

You shouldn't mount encrypted drives on sys-usb. Use qvm-block to attach
the partition to a different VM, then mount it there.

[Bernhard]

> You shouldn't mount encrypted drives on sys-usb. Use qvm-block to attach
> the partition to a different VM, then mount it there.
>

This is a good question, I think. Since we distrust sys-usb I agree that
we should not do the cryptsetup operations in sys-usb. But if you
distrust the attached device as well (might be safer, right?), one might
attach the luks-partition (resp. file) first to an intermediate (even
temp !) VM, luksOpen it in there and re-attach the generated /dev/mapper
volumes to the destination VM. That way sys-usb is blind to cryptsetup
and the destination-vm is maximally protected from usb-based attacks.
Overkill?

Bernhard

[awokd]

I think it's a bit overkill for partition based LUKS volumes, using
qvm-block already gets you protection against usb attacks. File based ones
might benefit from the additional step, but not sure how much.

[Alex]

Can you elaborate?

1. What's the security benefit?
2. What are the steps to correctly restore by Qubes backups from a USB disk?
3. Is there anything in the backup tool UI that guides users towards the workflow you describe?

Thanks

Alex

[awokd]

On Sat, May 19, 2018 10:12 pm, Alex wrote:

>>You shouldn't mount encrypted drives on sys-usb. Use qvm-block to
>>attach
>>the partition to a different VM, then mount it there.
>
> Can you elaborate?
>
> 1. What's the security benefit?

Sys-usb, like sys-net, exist to protect the rest of your system from
potentially compromised hardware devices and low level attacks. Say you
plugged in a USB drive you happened to find laying on your front doorstep,
and it managed to compromise sys-usb but not your other VMs. If you then
passed through a second drive with qvm-block, the bad sys-usb still
wouldn't have access to the decrypted contents, but would if it's mounted
directly in sys-usb.

> 2. What are the steps to correctly restore by Qubes backups from a USB
> disk?

Mounting it directly in sys-usb is "correct" in that it works, but suggest
something like
https://www.mail-archive.com/qubes...@googlegroups.com/msg17265.html.

> 3. Is there anything in the backup tool UI that guides users towards the
> workflow you describe?

No. Closest might be the introduction to the
https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube section,
but I can't remember any more exactly where I learned this. Would it help
if it were in the FAQ section and/or backup/restore guide?

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bernhard:

That's basically what Split dm-crypt automates (with even more overkill):
https://github.com/rustybird/qubes-split-dm-crypt

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ7BAEBCgBmBQJbAdM6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfO78P+MOUh1UqQeXrpHcwOcj4M/mX
z9+5pAXGgCa2t+MinDZTGE8Wvfeb62U/gc8A8Uwqzqs5g1NkGOQER2Z+azMS+Xnt
y9XukE3PE8MRA4XgfSZzreh6xOt8AZX8QRTNzlsPet+QjteKGW3B5tk2wBtzeTIU
Y+teN5cIKIWWXPy4AZPYbCDK9aXVYd0Za0/Dj6+Tcn1tuoGbOt4Gr1rLigql6Pi9
3Z1cpkK8VecoXIvOixxycYEBNAr6n7pMW35OjBCpbyB0uGHMXcZFqkoBFca2kOOb
HQbZwRLMlOQnI6DGF9O0jx5unabsnOli5OUXMWHdn1Xo/PMiNSWez02tNJkCFB/4
byhLi7b6p94DnWGyg4WJCi9XkMQ3nkEtNG0a2obvvjDF6bam0X9dRFwfbT7CiNLV
PleQFQjvoLFZJK/tVicnQyQVcTt2KeLD0nzzhqHe+At6XTPeiyBhf8mDERL8pIYr
FVws8oRGmKs2UHeRuFT16CmUN59xjrUuZv2Lf2q/I7Zlncv7pnBfQ5V/h+xT/gim
6K3l8xOBrspV4PRO20XAAQZ1i2NaDzZ8HBig+1q3hfhvMlFfzOT6EmrNk/oSTsSh
W4XO8R0L8wz5cZjHnJJU99UAooyUWj9jBiLbDd/1UT7RG8apHCXHriUpgMaFnAPo
nNT9XnACZNM4zkeA0NI=
=Lh2Z
-----END PGP SIGNATURE-----