[linux-lvm] lvm protected against crypt/luks

[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.

Re: [linux-lvm] lvm protected against crypt/luks

[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

Re: [linux-lvm] lvm protected against crypt/luks

[f-lvm]

    > Date: Mon, 7 Mar 2016 17:31:36 +0000
    > From: lejeczek <peljasz@yahoo.co.uk>

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

Re: [linux-lvm] lvm protected against crypt/luks

[Bryn M. Reeves]

On Mon, Mar 07, 2016 at 03:03:10PM -0500, John Stoffel wrote:
> 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.
 
> 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.

Re: [linux-lvm] [Bulk] Re: lvm protected against crypt/luks

[lejeczek]

On 08/03/16 11:12, Bryn M. Reeves wrote:
> On Mon, Mar 07, 2016 at 03:03:10PM -0500, John Stoffel wrote:
>> 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.
>   
>> 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.

> 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
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] [Bulk] Re: lvm protected against crypt/luks

[Ondrej Kozina]

On 03/08/2016 03:02 PM, lejeczek wrote:
> superb, thanks chaps,
> on keyfiles, would you know why this:
>
> 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

Re: [linux-lvm] [Bulk] Re: lvm protected against crypt/luks

[lejeczek]

On 08/03/16 14:14, Ondrej Kozina wrote:
> On 03/08/2016 03:02 PM, lejeczek wrote:
>> superb, thanks chaps,
>> on keyfiles, would you know why this:
>>
>> 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?
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] [Bulk] Re: lvm protected against crypt/luks

[Ondrej Kozina]

On 03/08/2016 04:36 PM, lejeczek wrote:
> On 08/03/16 14:14, Ondrej Kozina wrote:
>> On 03/08/2016 03:02 PM, lejeczek wrote:
>>> superb, thanks chaps,
>>> on keyfiles, would you know why this:
>>>
>>> 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.