1 |
On Sun, Mar 27, 2022 at 04:04:45PM -0500, Dale wrote: |
2 |
> Based on the reply from Rich, thanks for the info, cryptsetup is just a |
3 |
> upper level of dm-crypt. Basically, cryptsetup just has some user |
4 |
> friendly bits added on top of it. Security wise, should be secure |
5 |
> either way. |
6 |
|
7 |
To be clear, cryptsetup is just a userspace command line tool for |
8 |
manipulating dm-crypt/LUKS stuff. dm-crypt is the kernel part. Lots of |
9 |
tools are structured this way. LVM is a thing in the kernel, and the |
10 |
lvcreate/pvcreate/etc. command line tools are just the userspace user |
11 |
interface. I assume they probably use a bunch of complicated ioctl() |
12 |
calls on the LVM block devices to do their magic. |
13 |
|
14 |
dm-crypt wraps an existing block device. What it wraps is typically a |
15 |
physical disk partition, but it does not have to be. It can wrap |
16 |
basically any block device. |
17 |
|
18 |
The 'device mapper' idea is a key part of what makes all these tools |
19 |
composable: they use block devices to implement other block devices, |
20 |
which can then be the 'inputs' to other such tools, etc. dm-crypt takes |
21 |
a block device and uses it to implement a new block device. Its key |
22 |
property is that (if you follow some basic rules) it is impossible |
23 |
without the key to obtain the data inside it just by looking at the |
24 |
underlying block device. |
25 |
|
26 |
LVM is similar, but it has a different purpose. It takes some set of |
27 |
underlying block devices (physical volumes) and it presents a different |
28 |
set of block devices (logical volumes) to you. Its key property is that |
29 |
it is a much more flexible way of arranging volumes (basically |
30 |
"partitioning") than the underlying MBR/GPT disk partitioning system. |
31 |
|
32 |
You can compose these things in multiple ways. You can use dm-crypt on |
33 |
its own. You can use LVM on its own. You can use dm-crypt on top of |
34 |
LVM (so you have physical disk partitions as physical volumes, then some |
35 |
or all of your logical volumes act as the underlying block devices for |
36 |
dm-crypt's purposes). Or you can use LVM on top of dm-crypt (so your |
37 |
LVM "physical" volumes are dm-crypt block devices). |
38 |
|
39 |
And of course at some point as the final layer you put filesystems on |
40 |
top of all of this. |
41 |
|
42 |
My personal setup, to give an example, is that on each physical disk I |
43 |
have a single partition. I use dm-crypt (with LUKS, which is basically |
44 |
'dm-crypt but sane', more on that later) on those partitions. In other |
45 |
words, each physical disk in my computer has a single dm-crypt "volume". |
46 |
|
47 |
Each dm-crypt block device is then used as a physical volume for LVM. |
48 |
They are all in a volume group, and on top I have a number of logical |
49 |
volumes. Each logical volume then has ext4 on it. |
50 |
|
51 |
Here is what that looks like: |
52 |
|
53 |
NAME TYPE FSTYPE LABEL SIZE MOUNTPOINTS |
54 |
sda disk 3.6T |
55 |
`-sda1 part crypto_LUKS 3.6T |
56 |
`-hdd crypt LVM2_member 3.6T |
57 |
`-vg-videovol lvm ext4 VIDEO 100G /mnt/videos |
58 |
nvme0n1 disk 1.8T |
59 |
`-nvme0n1p1 part crypto_LUKS 1.8T |
60 |
`-root crypt LVM2_member 1.8T |
61 |
|-vg-rootvol lvm ext4 ROOT 100G / |
62 |
|-vg-swapvol lvm swap SWAP 64G [SWAP] |
63 |
|-vg-homevol lvm ext4 HOME 100G /home |
64 |
`-vg-audiovol lvm ext4 AUDIO 100G /mnt/audio |
65 |
|
66 |
> The biggest thing, can I encrypt a LVM group and then expand it. It |
67 |
> seems I can. I've found where google results say the same but some |
68 |
> results are dated. Things change. Sometimes for the good, sometimes not. |
69 |
|
70 |
You can, but there is more than one way to do it, and you should be sure |
71 |
you're doing it in the best way for what you need. |
72 |
|
73 |
If you only want some of your LVM logical volumes to be encrypted, it |
74 |
would make most sense to use LUKS on top of LVM. That's the opposite of |
75 |
the way I show I have it set up above. That means you'd have disk |
76 |
partitions as LVM physical volumes and you'd put LUKS on top of the LVM |
77 |
logical volumes. The encryption (dm-crypt layer) would only be on some |
78 |
of your volumes. And it would be above the LVM layer. However, I'm not |
79 |
sure why you would want this. |
80 |
|
81 |
There are a million and one ways of laying stuff out. You could have a |
82 |
set of disks that are for encrypted stuff and a set of disks that are |
83 |
not. Then you could put all the encrypted disks together into an LVM volume |
84 |
group and put things you want encrypted in the logical volumes in your |
85 |
'encrypted' volume group, while you put the things you don't want |
86 |
encrypted in the logical volumes in your 'unencrypted' volume group. |
87 |
|
88 |
I think you can even set things up so that logical volumes are fixed to |
89 |
a particular physical volume. Then you could have some of the physical |
90 |
volumes in your (single) volume group be encrypted, and others not, and |
91 |
assign logical volumes you want to be encrypted to the right physical |
92 |
volumes. But that seems very error-prone: I can definitely imagine you |
93 |
accidentally moving a meant-to-be-secret logical volume to the wrong pv |
94 |
and wham suddenly it's all being written out to disk in plaintext. |
95 |
|
96 |
Talking of plaintext, if you want to encrypt data you have on disks you |
97 |
should make sure that you _wipe the disks_ once you've moved that data |
98 |
off them. There's little value in the encryption if the original copies |
99 |
of the data are all still there on the drives in plaintext. You can use |
100 |
hdparm to securely wipe the drives. If it's a modern SSD it can |
101 |
probably do it instantly, because it actually stores the data on disk |
102 |
encrypted, and all it needs to do is wipe the key. If you have a hard |
103 |
drive then sadly you probably need to wait a long time for it to be |
104 |
wiped. It's going to take a hell of a long time for your system to |
105 |
overwrite every sector of an 8 TiB hard drive. This is another good |
106 |
reason for just encrypting everything yourself too: it makes it very |
107 |
easy to wipe your drives later: if you delete the key then it's all |
108 |
unrecoverable. |
109 |
|
110 |
The Arch linux wiki has a good overview of different ways of organising |
111 |
all of this, including the difference between plain dm-crypt and LUKS |
112 |
(just use LUKS), LVM on LUKS vs LUKS on LVM, encrypted boot, encrypted |
113 |
swap, etc. Most of what they say is pretty much directly applicable to |
114 |
Gentoo. The main difference is that they have their own very different |
115 |
way of doing initramfs setup, so you'll need to look at Gentoo-specific |
116 |
resources for that or work it out yourself. |
117 |
|
118 |
https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Overview |
119 |
|
120 |
https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption |