Talk:Dm-crypt/Specialties

From ArchWiki

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)Reply

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)Reply

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)Reply
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)Reply
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)Reply
Moved to Talk:Dm-crypt/Specialties. -- Alad (talk) 04:07, 25 August 2015 (UTC)Reply
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)Reply
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)Reply
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)Reply
Agreed on (4), let's wait until somebody else exhumes this thread, if that ever happens. — Kynikos (talk) 15:32, 15 September 2015 (UTC)Reply

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)Reply

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply
Okay those are fixed and thanks for the suggestions, how is it looking now? -- Wincraft71 (talk) 15:41, 4 January 2018 (UTC)Reply
You forgot these empty lines. -- nl6720 (talk) 15:57, 4 January 2018 (UTC)Reply
Thanks for the assist, besides the out of scope backup section, what should we do now? -- Wincraft71 (talk) 16:15, 4 January 2018 (UTC)Reply
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)Reply
Are there any other pseudo-variables that I need? -- Wincraft71 (talk) 17:01, 4 January 2018 (UTC)Reply
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)Reply
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)Reply
It is now simplified -- Wincraft71 (talk) 10:38, 13 January 2018 (UTC)Reply
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)Reply
I flagged dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB for removal. It hasn't been kept up to date and there seem to be some errors in it (e.g. an empty /dev/mapper/lukskey is used as a keyfile). -- nl6720 (talk) 07:30, 11 August 2024 (UTC)Reply

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)Reply

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)Reply
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)Reply
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)Reply

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)Reply

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-extrasAUR. Wolegis (talk) 19:10, 17 April 2023 (UTC)Reply

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)Reply

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)Reply

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)Reply
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)Reply

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)Reply

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)Reply

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)Reply

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)Reply
I took the liberty to revise the note about mkinitcpio-systemd-tool. Wolegis (talk) 12:30, 15 December 2023 (UTC)Reply

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)Reply

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)Reply