[Pkg-cryptsetup-devel] LVM on encrypted device?

[Jonas Meurer]

On 02/02/2006 Hadmut Danisch wrote:
> Yup. The RAID record could reveal information, such as the name, when
> last mounted, and things like that. It could further be systematically
> modified by an attacker. 
> 
> If you put encryption on RAID, then all raid disks must have the same
> encryption key. Maybe not wanted. 
> 
> When removing one RAID disk (e.g. because of failure) an attacker
> could compare the disk with the other disk and see how many sectors
> have been changed meanwhile. Could even try a replay attack by copying
> sectors back to the other disk. 
> 
> I admit these conditions are rather rare and may occur seldomly. This
> was just an example. Putting LVM on encryption would be significantly
> more important.

accepted, it would be useful to support that.

> > correct, current debian cryptsetup packages don't support lvm over
> > cryptsetup. is this often used?
> 
> No, because it's not supported. The chicken-and-egg problem. 

i meant in general, not in the debian world.

> > yes, maybe running cryptdisks twice would be the best. but how to check
> > whether a device is a physical one or not? i'm not sure about how to
> > realize that.
> 
> Maybe just check whether the device entry exists? 
> /dev/hda3 exists at the first run, 
> /dev/mapper/example does not, but at the second run.

that would be the easiest way. and it even would solve another problem:
if a removable device is not available, it's simply not mentioned. that
makes encrypted removable devices even more secure.
only if /etc/fstab has an entry for the fs on the removable media, boot
process breaks.

> Or just treat /dev/mapper differently?

no, i don't like that idea, as people could also use /dev/vg_name/*, and
maybe not only lvm suffers from that problem (i don't know for example
about evms etc.).

i like the idea, that cryptdisks checks for the existance of the source
device before running cryptsetup over it. and running cryptdisks twice
in the boot process shouldn't be too hard.

...
 jonas