lvm protected against crypt/luks
hi there
would you know if kernel/lvm protects PVs (or any other parts for that matter) from being encrypted? Do I need to wipe block devices clean off any LVM traces in order to encrypt them? BTW, LVs cannot be luks encrypted, can they?
many thanks.
lejeczek> would you know if kernel/lvm protects PVs (or any other lejeczek> parts for that matter) from being encrypted?
Not beyond the usual unix permissions. I.e. user's can't generally write to raw volumes/PVs/LVs. But root can do whatever it wants. Sometimes it tries to stop you from over-writing mounted filesystems, but that can be gotten around without much hassle.
lejeczek> Do I need to wipe block devices clean off any LVM traces in lejeczek> order to encrypt them?
No... but it's probably a good idea to do so initially, which is really to just zero it out. But LV information is stored within the VG, which is stored within the PVs which make it up.
So when you do a pvremove, it will wipe the device which holds the VG data.
lejeczek> BTW, LVs cannot be luks encrypted, can they?
Of course they can. Then you just loop mount the encrypted LUKS device (physical disk or LV, or even a file) and then put a filesystem on the new device. Then you mount that filesystem and away you go.
I would look up on google for beginner tutorials on using LUKs.
John
Quoted 6 lines · John Stoffel
lejeczek> Do I need to wipe block devices clean off any LVM traces in lejeczek> order to encrypt them?
No... but it's probably a good idea to do so initially, which is really to just zero it out. But LV information is stored within the VG, which is stored within the PVs which make it up.
Better to overwrite it with garbage (/dev/urandom for e.g.). This can take a very long time for large volumes but makes attacks on the ciphered data harder.
The Arch wiki has some discussion of this:
https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation
You also need to decide where you want the encrypted layer to sit:
you can encrypt PVs (meaning that the entire volume group using those PVs is encrypted), or you can encrypt individual LVs.
The choice depends on what you want to protect and how much of a performance penalty you are willing to take for the encryption.
Quoted 3 lines
Of course they can. Then you just loop mount the encrypted LUKS device (physical disk or LV, or even a file) and then put a filesystem on the new device. Then you mount that filesystem and away you go.
No need for loop devices or mounts - a dm-crypt layer looks just like a regular linear device-mapper device and can be mounted or passed to tools like mkfs just like any other.
The only extra things you have to deal with are the rather long UUID-based names that luks uses by default and the need to give the passphrase or key to unlock the device at boot or activation time - there are mechanisms integrated in most modern distros to assist with this either via configuration files or interactive prompts.
Again, Arch have a pretty good overview in their wiki:
https://wiki.archlinux.org/index.php/Dm-crypt
Regards,
Bryn.
Quoted 13 lines · Bryn M. Reeves
Quoted 6 lines · John Stoffel
lejeczek> Do I need to wipe block devices clean off any LVM traces in lejeczek> order to encrypt them?
No... but it's probably a good idea to do so initially, which is really to just zero it out. But LV information is stored within the VG, which is stored within the PVs which make it up.
Better to overwrite it with garbage (
/dev/urandomfor e.g.). This can take a very long time for large volumes but makes attacks on the ciphered data harder.The Arch wiki has some discussion of this:
Quoted 12 lines
https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation
You also need to decide where you want the encrypted layer to sit:
you can encrypt PVs (meaning that the entire volume group using those PVs is encrypted), or you can encrypt individual LVs.The choice depends on what you want to protect and how much of a performance penalty you are willing to take for the encryption.
Quoted 3 lines
Of course they can. Then you just loop mount the encrypted LUKS device (physical disk or LV, or even a file) and then put a filesystem on the new device. Then you mount that filesystem and away you go.
superb, thanks chaps,
on keyfiles, would you know why this:
cryptsetup luksOpen /dev/h300Int1/0 h300Int1.0_crypt /etc/crypttab.key --keyfile-offset 12
won't work? Whenever I use offset, I will not get:
Key slot 0 unlocked.
Command successful.
thanks.
Quoted 24 lines
No need for loop devices or mounts - a dm-crypt layer looks just like a regular linear device-mapper device and can be mounted or passed to tools like mkfs just like any other.
The only extra things you have to deal with are the rather long UUID-based names that luks uses by default and the need to give the passphrase or key to unlock the device at boot or activation time - there are mechanisms integrated in most modern distros to assist with this either via configuration files or interactive prompts.
Again, Arch have a pretty good overview in their wiki:
https://wiki.archlinux.org/index.php/Dm-crypt
Regards,
Bryn._______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Quoted 6 lines · lejeczek
superb, thanks chaps,
on keyfiles, would you know why this:cryptsetup luksOpen
/dev/h300Int1/0h300Int1.0_crypt/etc/crypttab.key--keyfile-offset 12
IIUC it seems like missing -d/--key-file option in front of "/etc/crypttab.key" string. Well it also depends on actual content of your /etc/crypttab.key file. Does it really contain backup of your keyslot passphrase (human readable text data)? Or does it contain volume key for your luks device (usually looks like binary data, bunch of random bytes that really should not be human readable:))
Regards
Ondrej
Quoted 4 lines · Ondrej Kozina
Quoted 3 lines · lejeczek
superb, thanks chaps,
on keyfiles, would you know why this:
Quoted 8 lines
Quoted 3 lines
cryptsetup luksOpen
/dev/h300Int1/0h300Int1.0_crypt/etc/crypttab.key--keyfile-offset 12IIUC it seems like missing -d/--key-file option in front of "
/etc/crypttab.key" string. Well it also depends on actual content of your/etc/crypttab.keyfile. Does it really contain backup of your keyslot passphrase (human readable text data)? Or does it contain volume key for your luks device (usually looks like binary data, bunch of random bytes that really should not be human readable:))Regards
Ondrej
many thanks Onrej,
it seems I got it completely wrong, the concept of it, I thought the keyfile is pure randomness and I just simply pick up a chunk of it with the help of offest. But why then it works fine without offset, with no passphrase in keyfile at any time?
Quoted 7 lines
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Quoted 17 lines · lejeczek
Quoted 16 lines · Ondrej Kozina
Quoted 6 lines · lejeczek
superb, thanks chaps,
on keyfiles, would you know why this:cryptsetup luksOpen
/dev/h300Int1/0h300Int1.0_crypt/etc/crypttab.key--keyfile-offset 12IIUC it seems like missing -d/--key-file option in front of "
/etc/crypttab.key" string. Well it also depends on actual content of your/etc/crypttab.keyfile. Does it really contain backup of your keyslot passphrase (human readable text data)? Or does it contain volume key for your luks device (usually looks like binary data, bunch of random bytes that really should not be human readable:))
Quoted 8 lines
Quoted 2 lines
Regards
Ondrejmany thanks Onrej,
it seems I got it completely wrong, the concept of it, I thought the keyfile is pure randomness and I just simply pick up a chunk of it with the help of offest. But why then it works fine without offset, with no passphrase in keyfile at any time?
Ok, let's return back to the origin. How did you create your encrypted device? Did you use cryptsetup luksFormat command? If so what options did you pass to it? In a default mode luksFormat command generates a random volume key for the device but also asks you for a passphrase. The passphrase is later used in cryptsetup open command when activating the encrypted device.
Anyway, if you have further questions this is proper list for cryptsetup/dm-crypt discussions:
http://www.saout.de/mailman/listinfo/dm-crypt
O.
Quoted 7 lines
Date: Mon, 7 Mar 2016 17:31:36 +0000
From: lejeczek <[email protected]>hi there
would you know if kernel/lvm protects PVs (or any other parts for that matter) from being encrypted?
Not that I've ever seen.
Quoted 2 lines
Do I need to wipe block devices clean off any LVM traces in order to encrypt them?
No.
Quoted 1 line
BTW, LVs cannot be luks encrypted, can they?
Yes, they can. I do this routinely.
LVM is agnostic about what's inside any LV. They're just blocks.
I often build filesystems with either bare disk or RAID on the bottom, with LVM on top of that, LUKS on top of that, and ext4fs (for example) on top of that. By using LVM under LUKS, I can make a single FS that spans multiple disks but is entirely encrypted with a single key.