On Sun, Mar 27, 2022 at 04:04:45PM -0500, Dale wrote:
> Based on the reply from Rich, thanks for the info, cryptsetup is just a
> upper level of dm-crypt.  Basically, cryptsetup just has some user
> friendly bits added on top of it.  Security wise, should be secure
> either way. 

To be clear, cryptsetup is just a userspace command line tool for
manipulating dm-crypt/LUKS stuff.  dm-crypt is the kernel part.  Lots of
tools are structured this way.  LVM is a thing in the kernel, and the
lvcreate/pvcreate/etc. command line tools are just the userspace user
interface.  I assume they probably use a bunch of complicated ioctl()
calls on the LVM block devices to do their magic.

dm-crypt wraps an existing block device.  What it wraps is typically a
physical disk partition, but it does not have to be.  It can wrap
basically any block device.

The 'device mapper' idea is a key part of what makes all these tools
composable: they use block devices to implement other block devices,
which can then be the 'inputs' to other such tools, etc.  dm-crypt takes
a block device and uses it to implement a new block device.  Its key
property is that (if you follow some basic rules) it is impossible
without the key to obtain the data inside it just by looking at the
underlying block device.

LVM is similar, but it has a different purpose.  It takes some set of
underlying block devices (physical volumes) and it presents a different
set of block devices (logical volumes) to you.  Its key property is that
it is a much more flexible way of arranging volumes (basically
"partitioning") than the underlying MBR/GPT disk partitioning system. 

You can compose these things in multiple ways.  You can use dm-crypt on
its own.  You can use LVM on its own.  You can use dm-crypt on top of
LVM (so you have physical disk partitions as physical volumes, then some
or all of your logical volumes act as the underlying block devices for
dm-crypt's purposes).  Or you can use LVM on top of dm-crypt (so your
LVM "physical" volumes are dm-crypt block devices).

And of course at some point as the final layer you put filesystems on
top of all of this.

My personal setup, to give an example, is that on each physical disk I
have a single partition.  I use dm-crypt (with LUKS, which is basically
'dm-crypt but sane', more on that later) on those partitions.  In other
words, each physical disk in my computer has a single dm-crypt "volume".  

Each dm-crypt block device is then used as a physical volume for LVM.
They are all in a volume group, and on top I have a number of logical
volumes.  Each logical volume then has ext4 on it.

Here is what that looks like:

  NAME               TYPE   FSTYPE       LABEL  SIZE  MOUNTPOINTS
  sda                disk                       3.6T
  `-sda1             part   crypto_LUKS         3.6T
    `-hdd            crypt  LVM2_member         3.6T
      `-vg-videovol  lvm    ext4         VIDEO  100G  /mnt/videos
  nvme0n1            disk                       1.8T
  `-nvme0n1p1        part   crypto_LUKS         1.8T
    `-root           crypt  LVM2_member         1.8T
      |-vg-rootvol   lvm    ext4         ROOT   100G  /
      |-vg-swapvol   lvm    swap         SWAP    64G  [SWAP]
      |-vg-homevol   lvm    ext4         HOME   100G  /home
      `-vg-audiovol  lvm    ext4         AUDIO  100G  /mnt/audio

> The biggest thing, can I encrypt a LVM group and then expand it.  It
> seems I can.  I've found where google results say the same but some
> results are dated.  Things change.  Sometimes for the good, sometimes not. 

You can, but there is more than one way to do it, and you should be sure
you're doing it in the best way for what you need.

If you only want some of your LVM logical volumes to be encrypted, it
would make most sense to use LUKS on top of LVM.  That's the opposite of
the way I show I have it set up above.  That means you'd have disk
partitions as LVM physical volumes and you'd put LUKS on top of the LVM
logical volumes.  The encryption (dm-crypt layer) would only be on some
of your volumes.  And it would be above the LVM layer.  However, I'm not
sure why you would want this.

There are a million and one ways of laying stuff out.  You could have a
set of disks that are for encrypted stuff and a set of disks that are
not.  Then you could put all the encrypted disks together into an LVM volume
group and put things you want encrypted in the logical volumes in your
'encrypted' volume group, while you put the things you don't want
encrypted in the logical volumes in your 'unencrypted' volume group.

I think you can even set things up so that logical volumes are fixed to
a particular physical volume.  Then you could have some of the physical
volumes in your (single) volume group be encrypted, and others not, and
assign logical volumes you want to be encrypted to the right physical
volumes.  But that seems very error-prone: I can definitely imagine you
accidentally moving a meant-to-be-secret logical volume to the wrong pv
and wham suddenly it's all being written out to disk in plaintext. 

Talking of plaintext, if you want to encrypt data you have on disks you
should make sure that you _wipe the disks_ once you've moved that data
off them.  There's little value in the encryption if the original copies
of the data are all still there on the drives in plaintext.  You can use
hdparm to securely wipe the drives.  If it's a modern SSD it can
probably do it instantly, because it actually stores the data on disk
encrypted, and all it needs to do is wipe the key.  If you have a hard
drive then sadly you probably need to wait a long time for it to be
wiped.  It's going to take a hell of a long time for your system to
overwrite every sector of an 8 TiB hard drive.  This is another good
reason for just encrypting everything yourself too:  it makes it very
easy to wipe your drives later:  if you delete the key then it's all
unrecoverable.

The Arch linux wiki has a good overview of different ways of organising
all of this, including the difference between plain dm-crypt and LUKS
(just use LUKS), LVM on LUKS vs LUKS on LVM, encrypted boot, encrypted
swap, etc.  Most of what they say is pretty much directly applicable to
Gentoo.  The main difference is that they have their own very different
way of doing initramfs setup, so you'll need to look at Gentoo-specific
resources for that or work it out yourself.

https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Overview

https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption

Reply via email to