[linux-lvm] lvm protected against crypt/luks

[lejeczek]

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.

[John Stoffel]

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

[Bryn M. Reeves]

Post by 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.

Post by John Stoffel
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.

[lejeczek]

Post by Bryn M. Reeves

Post by 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.
https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation
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.

Post by John Stoffel
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.

Post by Bryn M. Reeves
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.
https://wiki.archlinux.org/index.php/Dm-crypt
Regards,
Bryn.
_______________________________________________
linux-lvm mailing list
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Ondrej Kozina]

Post by lejeczek
superb, thanks chaps,
cryptsetup luksOpen /dev/h300Int1/0 h300Int1.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

[lejeczek]

Post by Ondrej Kozina

Post by lejeczek
superb, thanks chaps,
cryptsetup luksOpen /dev/h300Int1/0 h300Int1.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

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?

Post by Ondrej Kozina
_______________________________________________
linux-lvm mailing list
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Ondrej Kozina]

Post by lejeczek

Post by Ondrej Kozina

Post by lejeczek
superb, thanks chaps,
cryptsetup luksOpen /dev/h300Int1/0 h300Int1.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

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?

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.

[f***@media.mit.edu]

Date: Mon, 7 Mar 2016 17:31:36 +0000
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.

Do I need to wipe block devices clean off any LVM traces in
order to encrypt them?

No.

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.