Talk:Dm-crypt/Encrypting an entire system

From ArchWiki
Jump to: navigation, search

LVM on LUKS on LVM

A while ago User:Indigo added a reference to the LVM on LUKS on LVM scenario with [1], which was later modified with [2], and finally deleted with [3].

IMO it would be interesting to restore it as a stub section here, like Dm-crypt/Encrypting_an_Entire_System#LUKS_on_software_RAID, waiting for somebody to fill it up, what do you think?

I've also found a forum thread: [4].

-- Kynikos (talk) 14:09, 18 February 2014 (UTC)

It sure is an interesting use case, but I am hesitant. The main reason is that it has to be certain that udev device discovery (be it with encrypt or sd-encrypt) is rock solid longterm for such a setup, see e.g. [5] for related problems. The edits you refer to originate from before that and also before systemd. Therefore I think it would be sensible to have developer input on viability/route for such a sandwich.
I am biased though, I generally prefer encryption as the first mapper. One reason is that it is very easy to seriously wreck a LUKS blockdevice with a single resize statement, if lvm hovers over it.
A final thought on LVM: crypttab offers vanilla flexibility for multiple disks. It would be interesting to know, if someone runs an Arch setup with multiple non-root fully encrypted disks, mounted via crypttab/fstab and joined to a single VG. That might be a worthwhile alternative extension for the shorter Dm-crypt/Encrypting_a_Non-Root_File_System ?
edit: before I forget - a variation of above alternative extension on the non-root page instead may be not to use LVM but have multiple non-root fully encrypted disks and use a btrfs raid1 inside it. Users experiences with that might also be interesting for others.
Plenty of food. Looking forward to read/learn other opinions/experiences. --Indigo (talk) 22:13, 18 February 2014 (UTC)
Thanks for all these interesting observations. Let's keep it on hold then, at least now we have a reminder for this case. -- Kynikos (talk) 05:33, 19 February 2014 (UTC)
Anytime. Good you brought it to the table. --Indigo (talk) 10:51, 19 February 2014 (UTC)

LUKS on LVM /tmp example

I don't think the example config for /tmp is correct. It uses tmpfs, which completely bypasses the physical disks (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. TravisE (talk) 10:27, 11 March 2014 (UTC)

You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --Indigo (talk) 20:06, 11 March 2014 (UTC)
I updated syntax: [6]
I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that?
--Indigo (talk) 22:45, 25 March 2014 (UTC)

LVM On LUKS Over Multiple Disks

What's to keep someone from making an LV spanning multiple encrypted disks using a custom mkinitcpio hook, similar to [7]? They should be treated just like any other physical volumes. I tested an LV on two encrypted loop devices and it seemed to work. --Robomica (talk) 04:09, 12 July 2015 (UTC)

Nothing. Have a look at the methods described in Dm-crypt/Specialties#The encrypt hook and multiple disks. --Indigo (talk) 13:22, 12 July 2015 (UTC)

Encrypted boot (GRUB): no need for separate partition?

Exploiting GRUB#LVM, I've just tried the following scenario on VirtualBox, modified from Encrypted boot partition (GRUB):

+---------------+----------------+----------------+----------------+----------------+
|ESP partition: |Volume 1:       |Volume 2:       |Volume 3:       |Volume 4:       |
|               |                |                |                |                |
|/boot/efi      |boot            |root            |swap            |home            |
|               |                |                |                |                |
|               |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |
|/dev/sdaX      |----------------+----------------+----------------+----------------+
|unencrypted    |/dev/sdaY encrypted using LVM on LUKS                              |
+---------------+----------------+--------------------------------------------------+

It works perfectly fine, including the Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs trick. The result is clearly a lot simpler and neater, and allows avoiding Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2 altogether, again being able to unlock everything by entering the password only once.

Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.

The only problem I can think of is that Dm-crypt/Specialties#mkinitcpio-chkcryptoboot needs the partition to be separate, but we can merge Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2 there and leave a link from Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB) as a Tip.

Kynikos (talk) 14:11, 29 November 2015 (UTC)

LUKS on Software RAID

In my experience, I set up /etc/crypttab to map the RAID partition: /dev/md0, but after a reboot, the RAID partition changed to /dev/md127; so I had to change /etc/crypttab to contain the UUID of /dev/md127. This was not a system partion; it was just my data mounted at my user's directory in /home. –Kete (talk) 13:48, 27 March 2016 (UTC)

That usually happens, when the /etc/mdadm.conf has an error or is not present. I assume you might have followed something like the short script I posted to your user page for creating the raid. In that I forgot to include the RAID#Update configuration file steps, sorry! You can repeat the steps later though, the UUID that mdadm generates for /dev/md devices should be the one you (correctly) picked. If they are not, don't reboot/reactivate the raid until you have clarified. If you run them while the /dev/md126.. devices are active, those will be in the config but you can rename them (if wanted) before the reboot. Since we don't have instructions for raid yet in this article, I close this. Reopen if anything is unclear or a missing/wrong mdadm.conf was not the issue, thanks. --Indigo (talk) 18:03, 27 March 2016 (UTC)
Ok, weird stuff. I didn't leave out the config, but raid has gone back to md0. https://ptpb.pw/nSQiKete (talk) 19:02, 27 March 2016 (UTC)
Interesting. Do you have one of the mdadm hooks in your mkinitcpio.conf? --Indigo (talk) 08:44, 28 March 2016 (UTC)
Yes – HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck". Maybe this section needs more trials. –Kete (talk) 11:33, 28 March 2016 (UTC)
Well, there is no section content yet ;), but your input helps. Just a thought for the section: Maybe one way to add instructions for raid is to add a section that handles the stacking of LUKS onto a mdadm raid, in a general way.
Other than that, I think I know what the issue was in your case: You had the mdadm_udev hook in your initramfs, but maybe did not regenerate the initramfs after adding the raid? This might explain why it failed at first after raid creation; another kernel update regenerating the initramfs, which then included the mdadm.conf file. Possible? --Indigo (talk) 12:03, 28 March 2016 (UTC)
I've made a few tries and believe the mdadm_udev hook can only be the reason for your experience. It boots fine here whether mdadm.conf is present or not. I've added a tip for it with [8] and close this. Re-open if my assumption was wrong. --Indigo (talk) 10:19, 20 April 2016 (UTC)

Full disk encryption with LUKS (encrypted LVM with swap and root)

I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does. https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/

Voukait (talk) 04:13, 6 May 2016 (UTC)

Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --Indigo (talk) 09:59, 6 May 2016 (UTC)
I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)
To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.
I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.
Anyway we should really find a place in this article where to list external links like that.
— Kynikos (talk) 05:03, 7 May 2016 (UTC)
Yes, why not use a regular Dm-crypt/Encrypting an entire system#See also section and use the description. For example
Other possibilities? --Indigo (talk) 09:50, 7 May 2016 (UTC)
Actually another possibility would be to simply use dm-crypt#See also. For example
If it gets many links, they could be grouped. --Indigo (talk) 13:16, 7 May 2016 (UTC)
I agree we can use dm-crypt#See also for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — Kynikos (talk) 04:06, 8 May 2016 (UTC)

should all of the mkinitcpio configs recommend adding the "keyboard" module?

This is documented in other places, but it's one of those things that's extremely confusing when you get it wrong, because if you forget it your USB keyboard "just doesn't work" and there's no indication of why. One could argue that adding the keyboard module is a waste of space for e.g. laptops, but I actually just ran into a situation where I was booting one of my laptop disks inside a desktop machine instead, and I *really* wished I'd included the `keyboard` module from the beginning. Manually decrypting a secondary disk and editing its mkinitcpio.conf to fix an issue like this is super tricky. Oconnor663 (talk) 18:22, 10 November 2016 (UTC)

keyboard hook is actually not a waste of space for laptops, some of them need it; see FS#50700. Only use case where it could be safely omitted is dm-crypt/Specialties#Remote unlocking of the root (or other) partition.
I removed "USB" from the keyboard hooks description in dm-crypt/System configuration#mkinitcpio, hopefully it will motivate more people to include it. -- nl6720 (talk) 10:59, 13 November 2016 (UTC)