On 08/13/2018 05:32 PM, joevio...@gmail.com wrote:
On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise wrote:
On 08/13/2018 04:47 PM,
Related question.
If I installed Qubes and used LUKS encryption (I have to run cryptsetup
openLuks just to see the LVM inside)... then I add physical drives to my Volume
Group, and start adding more AppVMs to the pool, that starts writing to the
PV...
Is the data on the new drive, encrypted?
Can anyone forensically pull data from those new AppVMs since it wasn't
originally a part of the LUKS encrypted drive?
Based on the sparse description I'd say No, the new space is not
encrypted. You have to add separate LUKS/dmcrypt block layers to those
new devices and then treat those dmcrypt block devices as the new pvs.
If you're doing this to qubes_dom0, then it could be a little tricky
getting all of the encrypted "pvs" to unlock at the same time during the
boot process. You'd need to investigate how crypttab and grub
accommodate that multi-volume setup.
--
Chris Laprise
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
I would imagine it would require a longer grub entry with rd.luks attributes
for other UUIDs.
Yes, but if you can get crypttab to accept multiple volumes that share a
keyfile or password then dracut may be able to setup the grub entries
automatically.
But it seems I have an LVM over LUKS configuration... when what I want is a
LUKS over LVM.
[...]
The problem is that Qubes 4.0 manipulates lvm directly so unless you opt
for Qubes managing your vms with Ext4 image files (not a nice way to
go), what you could end up with is:
lvm --> luks --> lvm --> device
And I don't think that could truly work under ideal conditions because
thats COW on top of COW. This is also the reason that Btrfs on lvm is
frowned upon... stacking this way is not reliable.
If I choose btrfs for my next install, I can avoid the LVM problems, but can I
expand onto new physical volumes by adding more drives?
IMO, Btrfs gives you some added reliability and simplicity - devices can
be added and removed with ease, even when it reduces overall space. But
since encryption is still a separate luks layer you're still faced with
managing multiple luks volumes under Btrfs.
The only other possibility I can think of is to experiment with ecryptfs
on top of Btrfs. If you got it to work with Qubes it could span physical
volumes easily and the main (only?) downside would be increased
vulnerability to _physical_ (not remote) attacks.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f0e94454-b91f-547b-17fd-f7697c2c4a31%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
