Talk:Dm-crypt/Specialties

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)

Discussion

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.

Source: http://sch1zo.github.com/blog/2012/05/08/downgrading-a-bad-kernel-on-arch-with-luks-and-lvm/

dm-verity

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:

• Help:Style#Command line text
• Help:Style#Code formatting
• Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...
• Help:Style/Formatting and punctuation#Pseudo-variables in file/command line contents
• Help:Style/Formatting and punctuation#File names and paths

Now about the content:

• dm-crypt/Specialties#Preparing the disk devices should not duplicate dm-crypt/Drive preparation. Don't provide the specific commands, just tell what needs to be done and like the appropriate article explaining how to do it. Also don't specify cryptsetup's hash, cypher, key-size etc. options, use the defaults and link to dm-crypt/Device encryption#Encryption options for LUKS mode. Try to avoid duplicating instructions already available in other wiki pages and link to them instead, the wiki is not a tutorial.
• dm-crypt/Specialties#The actual installation procedure and custom encrypt hook - use pseudo variables. /usr/lib/initcpio/ is package manager territory, custom hooks should be placed in /etc/initcpio/. If a file doesn't need to be changed just copy it, look at dm-crypt/Specialties#Modifying encrypt hook.

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)

Following nl6720's suggestions of using sd-encrypt instead of a custom encrypt hook and storing the keyfiles and the header in the initramfs, I have written an updated guide. I did not run into the problem with the systemd start job that Wincraft71 mentioned, it must have been fixed between 2018 and 2022. Speedybunny (talk) 15:51, 30 November 2022 (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)

mkinitcpio-chkcryptoboot

This method to check the integrity of the GRUB EFI stub function also and is better with an encrypted /boot partition, so it should not be in the "Securing the unencrypted boot partition" section. Maybe create a "Check GRUB EFI stub integrity" section could be more clear ?

Peapy (talk) 14:30, 10 April 2019 (UTC)

This hook isn't only for EFI. It also works with MBR, even though it doesn't check the post MBR gap (yet). Since it works with both, I don't think it belongs to an EFI specific section. Also, even though an encrypted boot partition is not a requirement, it is strongly advised to have one. I think this section is exactly where it belongs. Grazzolini (talk) 15:13, 10 April 2019 (UTC)

Yes you'r right, an EFI specific section isn't the good place, anyway it is exactly because an encrypted /boot partition is strongly advised that I think it should not be in "Securing the unencrypted boot partition" section. It's not a big deal, but I found this a little contradictory and maybe source of misunderstanding. Peapy (talk) 10:04, 11 April 2019 (UTC)

Indeed, it should be more in something like “Securing the unencrypted bootloader”. chkboot and AIDE are pointless to me, since they are only tamper-evident, but it’s too late. chkcryptoboot is in another category however. Archange (talk) 10:19, 11 April 2019 (UTC)

Remote unlocking (hooks: systemd, systemd-tool)

Has anyone been successful in setting this up? If so, then a brief overview of how to set this up would be useful. A step-by-step guide, like for the existing Remote unlocking (hooks: netconf, dropbear, tinyssh, ppp) section, would help explain how you set this up. Terry tibbles (talk) 07:31, 27 May 2020 (UTC)

The package mkinitcpio-systemd-tool mentioned in this section has effectively been abandoned. Only 4 commits in 2021 and only one (insignificant) in 2022. (See commits, issue #92 and issue #97.) I have started an alternative project mkinitcpio-systemd-extras that (IMHO) is more straight forward, taking advantage of the existing mkinitcpio infrastructure.

It's properly documented with GitHub wiki pages.

I'd like to replace the section by one mentioning mkinitcpio-systemd-extras^AUR. Wolegis (talk) 19:10, 17 April 2023 (UTC)

Thanks for your contribution/package. Since mkinitcpio-systemd-tool is still in official repos and you currently correspond with devs looking into porting functionality (of one or the other) to official support, the section best follows after that initiative is concluded. I've added Special:diff/775887 so that users are aware for now. --Indigo (talk) 08:59, 21 April 2023 (UTC)

Encryption of /boot ist not useful at all

Really, how does encrypting the /boot partition make the system any more secure? Signing it or its contents could, by ensuring the bootloader and kernel have not been tampered with, but it contains only generic system components and no personal data, so no point in encrypting it. --Bachsau (talk) 20:38, 24 November 2020 (UTC)

You can sign whatever you want, but if the bootloader won't verify itself, the kernel and initramfs before loading anything, it does not help at all. Also, the lack of personal data depends on each system, the fact that it's usually the case is not an excuse. -- Lahwaacz (talk) 21:40, 24 November 2020 (UTC)

Not to mention that for particularly security-sensitive systems, there can be some useful metadata in /boot for attackers to decide what vectors to try attacking. -- Clpwn (talk) 02:48, 25 November 2020 (UTC)

Remote unlocking (hooks: netconf, dropbear, tinyssh, ppp)

I just went through these instructions on October 19 2021 and had two issues:

• mkinitcpio-tinyssh usage of tinyssh-convert is broken
• Cannot get ip=dhcp or ip=:::::eth0:dhcp to work with mkinitcpio-netconf. Had to use a static address/gateway/mask (I used the same values I would get from DHCP). Note: dhcpcd works so I do not know what's wrong.

--Aureooms (talk) 19:05, 19 October 2021 (UTC)

Remote unlocking (hooks: arch-clevis)

I created a custom mkinitcpio hook that makes use of the clevis client to decrypt a root filesystem. It's not published to the AUR yet but if there's any interest I could put it up there and add it to this page. It should work out-of-the-box as long as a key slot bound to a tang server has been added to the root partition. Cthulhaire (talk) 00:39, 1 May 2022 (UTC)

systemd based initramfs (built with mkinitcpio)

there are some commits regarding fixing issues and a new release at Oct. 1, 2023.

https://github.com/random-archer/mkinitcpio-systemd-tool

perhaps making the tutorial revert back into main article instead of a Note? Brli (talk) 09:41, 15 December 2023 (UTC)

Yes, there was a new release recently. Unfortunately, nothing has improved on the documentation front. Mind the above comment about difficulties using mkinitcpio-systemd-tool. I used mkinitcpio-systemd-tool myself and was finally successful, but I second these statements.

IMHO, mkinitcpio-systemd-tool is still in dire need of proper documentation - either here or (preferably) on its GitHub page. Re-introducing the previous section about mkinitcpio-systemd-tool will not be very helpful, as it consisted mainly of a feature list and a reference to its README file. Wolegis (talk) 12:21, 15 December 2023 (UTC)

I took the liberty to revise the note about mkinitcpio-systemd-tool. Wolegis (talk) 12:30, 15 December 2023 (UTC)

TRIM with Luks and LVM

I see the sentence

Besides the kernel option, it is also required to periodically run fstrim or mount the filesystem (e.g. /dev/mapper/root in this example) with the discard option in /etc/fstab

Does it relevant. Why kernel parameter is not enough? How often do I need to run the fstrim manually?

discard option in /etc/fstab

Does it mean we gonna enable continuous trim? This is mentioned in the section about periodic trim. I would say it's hard for me to configure my system with those explanation. --Webcapcha (talk) 17:36, 14 April 2024 (UTC)

You need to enable TRIM on the LUKS volume as well as on the file system. For LUKS there is the kernel option (cryptdevice=/dev/sdaX:root:allow-discards or rd.luks.options=discard) that this sentence talks about, or the discard option for crypttab, or the --allow-discards option for cryptsetup. For the file system there is either fstrim or the discard mount option, both are described in TRIM (which is also linked from this page). — Lahwaacz (talk) 12:52, 17 April 2024 (UTC)