From ArchWiki
Jump to: navigation, search

Downgrade the kernel using LVM on LUKS

From Downgrade. I'm not familiar with this article series, so I'll have others decide on where it fits best. -- Alad (talk) 02:57, 25 August 2015 (UTC)


With my recent installation ISO, the dm_crypt and dm_mod modules are loaded automatically, and the lvm volume is activated automatically, so those commands can probably be removed from that section. Also, since this procedure is valid for any maintenance of an LVM on LUKS system, wouldn't it make more sense to have it on the LVM on LUKS page? Cmatteri (talk) 19:35, 20 March 2015 (UTC)

Well, there is no "LVM on LUKS" page. We had a discussion on similar issues [1] and currently have no place to put it appropriately. You have an idea where to link it? --Indigo (talk) 20:05, 20 March 2015 (UTC)
I was thinking of Dm-crypt/Encrypting_an_entire_system#LUKS_on_LVM. The subject of that page is installation, but that also means that just about everyone using that setup knows about that page and may look there for more information. I don't have strong feelings though, and you've had more time to think about the organization. Cmatteri (talk) 00:04, 21 March 2015 (UTC)
I've crosslinked it with [2], so we have a reference. If you shorten the content, I'd vote for leaving the lvm commands for activation in - just in case. --Indigo (talk) 10:36, 21 March 2015 (UTC)
Moved to Talk:Dm-crypt/Specialties. -- Alad (talk) 04:07, 25 August 2015 (UTC)
I'm undecided what we should do with this section. I see three alternatives:
  1. It may be dropped and we may add a sentence or two for some of the Dm-crypt/Encrypting an entire system scenarios about how to access it from the ISO for repairs.
  2. We make it more elaborate and add a subsection per scenario at the end for it.
  3. We add a general subsection in Dm-crypt/System_configuration with a couple examples
Something like unlocking a LUKS encrypted root from an ISO & LVM activation should be covered somewhere in my view, that's why I tried to save the section in the previous location :)
Opinions? --Indigo (talk) 14:01, 13 September 2015 (UTC)
I think that if one has understood how he's created his specific stack, he's also able to reopen it from a live system without too much hand holding (which in this case would then be redundant IMO).
For this reason I'm for solution 3), although I'm not sure if Dm-crypt/System configuration is the best place to put it. For example dm-crypt/Device encryption already mentions dm_crypt, and deals with other maintenance tasks like Dm-crypt/Device_encryption#Backup_and_restore.
Kynikos (talk) 10:36, 14 September 2015 (UTC)
I prefer (3) as well. But you are right, not such a big deal and another choice is (4) Skip the topic for now; not necessary, if readers understood what they setup.
Dm-crypt/Device encryption#Backup and restore is only about the header. I'd prefer that subpage to stick to the topics involved with the crypto/cryptsetup actions. Dm-crypt/System_configuration has more of the points one needs to touch when doing maintenance (fix fstab/crypttab, bootloader config). --Indigo (talk) 12:09, 14 September 2015 (UTC)
Agreed on (4), let's wait until somebody else exhumes this thread, if that ever happens. — Kynikos (talk) 15:32, 15 September 2015 (UTC)

Section (see discussion above)

Boot the Arch Linux installation ISO, and run the following commands to unlock the LUKS container and chroot into the system.

Load the necessary kernel modules:

# modprobe dm_crypt
# modprobe dm_mod

Unlock the LUKS container:

# cryptsetup luksOpen /dev/sdxY crypt

Scan for and activate LVM volumes:

# vgscan
# vgchange -ay

Create a folder for mounting and mount the partitions. Adapt this as necessary for the given system.

# mkdir /mnt
# mount /dev/mapper/LVM-partition /mnt

Mount the boot partition.

# mount /dev/sdxZ /mnt/boot

Chroot into the mounted filesystem.

# arch-chroot /mnt /bin/bash

At this point, follow the instructions in the previous section #Downgrading the kernel.



It might be helpful to mention dm-verity on this page and also to reference Secure_Boot —This unsigned comment is by MountainX (talk) 18:34, 31 May 2016‎. Please sign your posts with ~~~~!

Yes, both would be nice. For dm-verity I think it would be neater to let it have its own short article actually, which can be crosslinked from here and other articles like Secure Boot, etc. However, as long as there is no install instructions for it, it might as well be mentioned in Dm-crypt/Specialties#Other methods. Please go ahead, if you want. --Indigo (talk) 11:41, 2 June 2016 (UTC)

Encrypted /boot and a detached LUKS header on USB

Besides violating multiple style rules (which I couldn't be bothered to list in the style template) dm-crypt/Specialties‎#Encrypted /boot and a detached LUKS header on USB is over complicated for very little gain.

By not placing the keyfile and LUKS header in initramfs it only makes it more complex. A simpler solution would be to combine dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB) and dm-crypt/Specialties#Encrypted system using a detached LUKS header into something like:

+---------------+---------------+   +-----------------------+-----------------------+-----------------------+
|ESP:           |Boot partition:|   |Volume 1:              |Volume 2:              |Volume 3:              |
|               |               |   |                       |                       |                       |
|/boot/efi      |/boot          |   |root                   |swap                   |home                   |
|               |               |   |                       |                       |                       |
|               |               |   |/dev/mapper/store-root |/dev/mapper/store-swap |/dev/mapper/store-home |
|/dev/sda1      |/dev/sda2      +   +-----------------------+-----------------------+-----------------------+
|unencrypted    |LUKS encrypted |   |     /dev/sdb encrypted using LVM on LUKS with a detached header       |
+---------------+---------------+   +-----------------------------------------------------------------------+
|     USB drive /dev/sda        |   |                      HDD /dev/sdb (unpartitioned)                     |
+-------------------------------+   +-----------------------------------------------------------------------+

With sd-encrypt it wouldn't even require any custom hooks. -- nl6720 (talk) 10:11, 3 January 2018 (UTC)

That's what I initially did but when systemd handles the boot via crypttab.initramfs it adds an unnecessary start job for the keyfile and the system will only boot if you go to the emergency shell and mask that startjob using ln -s. Also that depends on the initramfs image having the header and keyfile inside of it, versus getting it in realtime from the USB directly. While it is more lines of code, the custom hook is easier to boot up with less waiting time. While simply combining different sections from different articles is one "solution", I believe putting it all together for future generations has more value of it own.
Regardless, having the header and keyfile on its own and not inserted into an image enhances security because it would completely require the USB drive to boot which is what I thought was the main point of having a seperate usb bootable key, versus having it on an image that does not necessarily depend on the USB to the same degree. While an attacker could theoretically copy the header if they can also access the initramfs image, I believe the extra layer of complexity and closing the keyfile before we boot into the system can mitigate this. Also note that the sections you reference have no instructions for creating a LUKS encrypted keyfile.
Another point is that without the embedded header in the initramfs, the user is easily able to "disable" a usb key by removing or corrupting the header, granted they have a well-protected and safe encrypted backup offline or in secure storage online. This would be useful for a scenario where a user needs a USB key to appear that it works but actually doesn't for somewhat of a plausible deniability. Otherwise, they would have to remake initcpio after removing it from /etc/mkinitcpio.conf then restore the old one to put the header back in.
Lastly, in the event that the header, initramfs, and keyfile have been taken from memory or the disk or otherwise compromised, or the user is simply reencrypting or changing keys preemptively, the user can go offline by disabling all networking and cryptsetup-reencrypt to change the master key (volume key) of the disk and header or change the keyfile using Dm-crypt/Specialties#Changing_the_LUKS_keyfile. All changes would simply work when they boot back into the system and require no regeneration of the initramfs. The user could even do it from an install cd or a live usb of a different linux operating system.
If you could please tell me specifically about the "multiple style rules" I have violated, I will gladly have that fixed as soon as possible. - Wincraft71 (talk) 02:43, 4 January 2018 (UTC)
Is there a bug report for the unnecessary systemd start job? It sounded like something I've seen referenced before, but after checking [3] that's a different issue.
I don't see the need to avoid placing the keyfile in initramfs when initramfs resides in a encrypted /boot. As long as /boot is not unlocked everything in it is safe™.
About style, read all of Help:Reading, Help:Editing, Help:Style, Help:Style/Formatting and punctuation, Help:Style/White space. At a quick glance I spot these issues:
Now about the content:
and more... -- nl6720 (talk) 10:19, 4 January 2018 (UTC)
That's the thing about /boot however, is that you have to mount it eventually for system updates (kernel files) or regenerating the initramfs (after you update the kernel), and in doing so expose it to potential attacks. The user will probably have the keyfile somewhere on their usb from when they generated it, and if somebody copies your keyfile or initramfs while /boot is unencrypted then you are hosed. The main need would be easy changing of the keyfile without having to regenerate the initramfs, and the extra privacy since boot does have to be eventually mounted. I believe I've seen something like that on Github issues for systemd when I was searching, but I can't remember exactly. I can try finding it from my browser history if you want. I thank you kindly for the necessary resources on improving the style, formatting, and content. I will begin immediately on improvements and come back to this talk page when they are done to see if there is anything else that needs to be done. - Wincraft71 (talk) 11:18, 4 January 2018 (UTC)
You forgot the whitespace after the prompt symbol. Why are there empty lines between commands and a weird indentation in customencrypthook dm-crypt/Specialties#The actual installation procedure and custom encrypt hook? Also unless it's a long code block it's preferred to start the line with a whitespace (Help:Editing#Code) instead of using Template:bc. -- nl6720 (talk) 14:39, 4 January 2018 (UTC)
Okay those are fixed and thanks for the suggestions, how is it looking now? -- Wincraft71 (talk) 15:41, 4 January 2018 (UTC)
You forgot these empty lines. -- nl6720 (talk) 15:57, 4 January 2018 (UTC)
Thanks for the assist, besides the out of scope backup section, what should we do now? -- Wincraft71 (talk) 16:15, 4 January 2018 (UTC)
dm-crypt/Specialties#Preparing the USB key need simplifying, preferably with links to Partitioning and EFI System Partition. dm-crypt/Specialties#The actual installation procedure and custom encrypt hook - the ls * stuff needs to disappear, link to Persistent block device naming#by-id and by-path and use pseudo variables. -- nl6720 (talk) 16:23, 4 January 2018 (UTC)
Are there any other pseudo-variables that I need? -- Wincraft71 (talk) 17:01, 4 January 2018 (UTC)
I don't think so.
Try to add more wikilinks and man page links for detailed explanations. For example for GRUB cryptodisk - GRUB#Boot partition. For efibootmgr instead of explaining all options link to efibootmgr(8). -- nl6720 (talk) 17:25, 4 January 2018 (UTC)
Instead of suggesting partition sizes link to Partitioning and use MiB & GiB instead MB & GB. dm-crypt/Specialties#Installation procedure and custom encrypt hook could use a bit of simplification, it should not reiterate the Installation guide. Just specify at which point these instructions should be used. -- nl6720 (talk) 15:18, 12 January 2018 (UTC)
It is now simplified -- Wincraft71 (talk) 10:38, 13 January 2018 (UTC)

The encrypt hook and multiple disks

Does this take into account virtual machines, and resizing the disk of the guest? Terry tibbles (talk) 07:12, 19 April 2018 (UTC)

My meaning with this was: there are sections for Expanding LVM on multiple disks and Modifying the encrypt hook for multiple partitions. Resizing the disk size of a virtual machine/VPS guest is a fairly common task. Does this need to be included as well? Terry tibbles (talk) 04:08, 28 May 2018 (UTC)
Resizing LVM is already thoroughly covered in LVM and related articles, it should not be included also here (there's already an lvextend example anyway), closed. -- Kynikos (talk) 11:22, 29 May 2018 (UTC)
What if the volume you're resizing is encrypted? Terry tibbles (talk) 10:06, 1 June 2018 (UTC)
See Resizing_LVM-on-LUKS from the sidebar of LVM -- Wincraft71 (talk) 02:56, 2 June 2018 (UTC)

Multiple non-root partitions

What about this? I just tried steps 4, 5, and 6 in Arch, and it works. You have to remember to run mkinitcpio -p linux instead of update-initramfs -u, but it's a lot less clunky than the current example. Terry tibbles (talk) 03:51, 24 May 2018 (UTC)

Your linked guide basically uses the setup described in dm-crypt/Encrypting a non-root file system#At boot time, the partitions will be unlocked only after switch root.
dm-crypt/Specialties#Multiple non-root partitions is specifically about unlocking the non-root partition(s) at the initramfs stage. Unless you really need to unlock the partition in the initramfs, it's easier to unlock it from crypttab after boot.
-- nl6720 (talk) 07:17, 24 May 2018 (UTC)