Talk:Dm-crypt/Encrypting an entire system

From ArchWiki

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

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

Rename volume group to be more consistent with device naming

I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful. —This unsigned comment is by Terry tibbles (talk) 08:13, 16 April 2018. Please sign your posts with ~~~~!

I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- nl6720 (talk) 08:32, 16 April 2018 (UTC)Reply
What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. Terry tibbles (talk) 08:21, 18 April 2018 (UTC)Reply
I think that "volgroup" sounds too generic. Previously the article had "MyStorage" and "lvm". I'm not good at naming things, so I can't think of a good replacement.
Actually I'm not even certain if there's a need to rename the current VG. -- nl6720 (talk) 09:09, 18 April 2018 (UTC)Reply
I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. Terry tibbles (talk) 09:25, 18 April 2018 (UTC)Reply
How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- nl6720 (talk) 09:44, 18 April 2018 (UTC)Reply
I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. Terry tibbles (talk) 06:37, 19 April 2018 (UTC)Reply
'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- Wincraft71 (talk) 10:58, 19 April 2018 (UTC)Reply
I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.
Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/group-volume path.
-- Kynikos (talk) 15:57, 20 April 2018 (UTC)Reply
From these, I'd vote for "MyVolGroup". -- nl6720 (talk) 16:17, 20 April 2018 (UTC)Reply
"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- Wincraft71 (talk) 16:45, 20 April 2018 (UTC)Reply
I don't think this is the appropriate article to explicitly state that uppercase is allowed, that's more in the scope of the LVM article. -- nl6720 (talk) 16:56, 20 April 2018 (UTC)Reply
Right, LVM is linked within this page and that would be a more proper place. 'VolGroup00' is another idea. -- Wincraft71 (talk) 19:08, 20 April 2018 (UTC)Reply
So I've replaced all the examples with "MyVolGroup".
The other articles mentioning LVM use all kinds of example names, but at least they do have "group", "vg", or even just a "g", enough to remind that it's a volume group, not a volume, so I don't see the need to update them, does anyone?
-- Kynikos (talk) 07:12, 21 April 2018 (UTC)Reply
It looks good. Terry may have implied both articles using the same name when he was referring to "consistency". It is an optional possibility, but LVM could be edited to use "MyVolGroup" for all volume group names. And also editing LVM#Create volume group to say something like "See lvm(8) for a list of valid characters for Volume Group names." -- Wincraft71 (talk) 18:04, 21 April 2018 (UTC)Reply
If we want cross-article consistency, all the articles in LVM's related box use examples of volume groups with different names. I don't have any problems if you add a reference to lvm(8). -- Kynikos (talk) 05:41, 22 April 2018 (UTC)Reply

Using UUIDs for device maps?

What is the point of using UUIDs to access device mapper devices (e.g., LVM)? Seems unnecessary. Neven (talk) 14:53, 6 January 2019 (UTC)Reply

The only useless use of UUID I can find is the cryptdevice in dm-crypt/Encrypting an entire system#Configuring_the_boot_loader_3 (in the LUKS on LVM scenario). That one was changed in Special:Diff/551821, presumably to be consistent with the rd.luks kernel parameters, which have the stupid limitation of only supporting UUIDs. -- nl6720 (talk) 16:20, 6 January 2019 (UTC)Reply
+1 to keeping it due to rd.luks example. Also, some years prior to sd-encrypt a lot of users of multiple DMs (e.g. raid/lvm or dm-crypt/lvm <--culprit;) had race conditions on device activation at boot. Sometime the links to Persistent block device naming were added, but the nomenclatura kept to keep it readable for the examples. --Indigo (talk) 18:11, 11 January 2019 (UTC)Reply
Btw, FS#60907 for sd-encrypt is similar in effect to what happened back then with encrypt. Odd. --Indigo (talk) 18:53, 12 January 2019 (UTC)Reply

Can we rename "Plain dm-crypt" to "LVM on plain dm-crypt"

This is because I want to add "GPT on plain dm-crypt". Note that this proposal is different from the change from before because of the explicit "plain" in the section title. Neven (talk) 01:20, 17 January 2019 (UTC)Reply

I see, can you make a very quick draft to understand better what you're proposing? What are advantages and disadvantages compared to the LVM method? If there isn't much difference perhaps it would be better to just add it as a variation Tip in the plain dm-crypt scenario? -- Kynikos (talk) 16:31, 18 January 2019 (UTC)Reply
The essential differences of using GPT instead of LVM are:
* Advantage: No need for userspace daemons (besides possibly udev, which is running constantly on almost all Archlinux machines anyways, I presume). Speculation: this means faster bootup.
* Disadvantage: There is currently no support for detecting and mapping GPT partitions that reside on device maps, like there is for LVM volumes. Thus the user would need to set up an Udev rule or just a command in a mkinitcpio hook to detect and map the GPT partitions as device mapper maps. Kpartx or partprobe can be used for that. (An alternative to using device mapper would be to use losetup to access the partitions as loopback devices, but I think that would be less performant.)
Another, small, change from the "Plain dm-crypt" section that I want to make in the new section is using only one removable flash drive instead of two. So the flash drive would have two partitions. Neven (talk) 23:54, 18 January 2019 (UTC)Reply
After reading the relevant mailing list thread, I came to the conclusion that the 'encrypted GPT use case' targets situation when 1) plain dm-crypt is desired for deniable encryption reasoning and LUKS header is avoided (note, this could be partially archived by detached LUKS header, personally I like plain dm-crypt, but many will object that deniable encryption of 500+GB space is nonsense) 2) user wants to encrypt several 'partitions' (in abstract sense) at once (without having 3+ separate partitions with different passwords) but does not want to use LVM for some reason (if LVM is avoided because of additional layer costs - this argument is weak, because what is the evidence that these costs are significant? how much does LVM reduce IO read/write? how much does it slow boot? If not costs, then what is the reason which makes LVM an unaccepted alternative?) 3) user wants to use filesystem which does not support 'logical' partitions, like btrfs, OR, if such system cannot have swap space. For example, a user wanting only ext4 partitions, or user wanting both btrfs AND swap partition (for example, he likes compiling Chrome browser). I may be wrong here, but propose that such type of information should be included. --Mxfm (talk) 12:47, 19 January 2019 (UTC)Reply
The "partition table on plain dm-crypt or LUKS" scenario would involve modifying/creating mkinitcpio hooks. As such I do not think it could be placed in dm-crypt/Encrypting an entire system. The only place for such a setup would be the same place where the "Encrypted system using a detached LUKS header" scenario is - dm-crypt/Specialties (aka dm-crypt/Weird and unusual setups). -- nl6720 (talk) 12:58, 19 January 2019 (UTC)Reply
Why would mkinitcpio hooks cut be the cut off point for what makes it in dm-crypt/Encrypting an entire system? That makes no sense. This proposed section would logically appear right beside the current "Plain dm-crypt" section, because it also uses "Plain dm-crypt", unlike the rest of the page which uses LUKS. Neven (talk) 13:15, 19 January 2019 (UTC)Reply
None of the other scenarios in dm-crypt/Encrypting an entire system require creating custom hooks. I don't think we should add such complex setups to this page. Regardless of that, I support renaming the "Plain dm-crypt" scenario to "LVM on plain dm-crypt" -- nl6720 (talk) 13:44, 19 January 2019 (UTC)Reply
Is creating a hook and adding it to mkinitcpio.conf really such a hassle? The page already suggests using some configuration files, like fstab and crypttab; so I do not see the rise in complexity from using hooks. Neven (talk) 13:50, 19 January 2019 (UTC)Reply
It might be, but I guess that depends on how complex it is. If the hook or udev rule could be packaged (even in AUR), then that would be even better. To clarify, I'm not trying to dissuade you, but without a ready draft it's hard for me to evaluate the scenario. -- nl6720 (talk) 14:01, 19 January 2019 (UTC)Reply
Just a single command is really necessary: either kpartx -a disk or partprobe disk. Neven (talk) 14:11, 19 January 2019 (UTC)Reply
If you look over the different scenarios on this scenario page, you won't find custom hooks/udev rules/etc. for now, because (1) they are meant as installation examples with the tools on the ISO, i.e. to keep focus. (2) Maintainability of non-standard tools/hooks is a general issue.
@Neven: reduction to one flash drive is mentioned in the first tip already. I'm against explicitly using a single flash, because it contravenes reasons to use plain dm-crypt in the first place. Remember boot loader configuration in the example gives away the location of a key-file, hence, if you have it on one flash ..
I'm +1 to nl6720's suggestion to add the custom hooks to a new subsection in dm-crypt/Specialties; there is more room to explain pros&cons of your new kpartx method. (mod note seems useful to continue this branch at the end of the next branch) --Indigo (talk) 14:42, 19 January 2019 (UTC)Reply
I see this is an interesting exercise, but without a clear technical definition of its benefits (which should have greater extent than other variations such as detached headers), its use cases would practically overlap those for the traditional LVM method, also in lack of scientific benchmarks that prove a noticeable performance improvement, so +1 to add this to the Specialties page and link to it from a Tip as a variation to the plain dm-crypt scenario.
Even if this method was considered distinct enough to be given a separate scenario (which I repeat I'm against at the moment), I think the hook should still be put in /Specialties and linked from the scenario.
-- Kynikos (talk) 06:40, 20 January 2019 (UTC)Reply

Maybe it would be even better to replace "dm-crypt" with "encryption" in the title, or maybe something like "LVM/GPT behind a ciphertext" would be even better. That is because dm-crypt is not a format, but rather just a method in the kernel of doing encryption without any header or metadata. Neven (talk) 10:18, 17 January 2019 (UTC)Reply

"Plain dm-crypt" is an expression that is used all over cryptsetup(8), maybe you're kind of right in ideal terms, but often technical jargon relies on conventional idioms that, despite not being literally correct, do a better job at conveying the intended meanings because of their widespread traditional usage, compared to perhaps more accurate but less recognized/able phrasings. -- Kynikos (talk) 16:31, 18 January 2019 (UTC)Reply
Now that I think about it, I only thought of this because I forgot that this page was about dm-crypt instead of about disk encryption in general. So, the parent paragraph can just be ignored. Neven (talk) 23:57, 18 January 2019 (UTC)Reply
Can you explain your proposal better? What exactly you want to change? Without clarifications, your proposal is controversial, because you essentially propose rename 'plain dm-crypt' to 'LVM on plain dm-crypt' which is obviously false. These are two different use cases and hiding one of them behind the other is incorrect. For example, I use plain dm-crypt, but do not use LVM. If you propose to rename entire page, than it seems uresonable, because in current form the page does not contain information only about LVM, it has sections regarding encrypted boot and swap. If you propose to rename specific section 'Plain dm-crypt', then it is also incorrect because that section has nothing to do with LVM. It looks like you have implicit assumption (from your experience) that there are only two use cases - LVM on plain dm-crypt and GPT on plain dm-crypt (and there is no plain dm-crypt without LVM/GPT use case). Contrary to this view, in my opinion the situation is completely different. The majority use cases are LUKS (possibly with LVM) and plain dm-crypt (possibly with LVM). The encrypted GPT use case is a new one which was covered in recent mailing list thread and could be supported in future. --Mxfm (talk) 12:25, 19 January 2019 (UTC)Reply
You are being kind of confusing here with your expression, so it seems to me that you are saying a lot of irrelevant or obviously false stuff, but I will try to respond anyway:
  • I am proposing to rename the "Plain dm-crypt" section, not the entire page.
  • The section in question is about LVM on plain dm-crypt, thus the proposed name. I can not fathom why would you say it is not about LVM.
  • I did not understand the stuff at the end at all. Neven (talk) 13:11, 19 January 2019 (UTC)Reply
I think Mxfm simply overread that you already dismissed the rename idea, and at the end Mxfm gave a first-hand example of why we can't feature full-length example scenarios for all possibilities.
Still, to me it is out of question that we should find a place where your approach can be explained adequately & currently I think the above suggestion to add to dm-crypt/Specialties and crosslinking it is best. Once that part is in place and linked to the existing plain dm-crypt example in this page, it is easier to decide if it makes sense to add a totally new scenario for it, or crosslinking from/to the plain dm-crypt scenario suffices. Thoughts? --Indigo (talk) 14:42, 19 January 2019 (UTC)Reply

Security Issue with Grub Keyfile

As-is, the Avoiding having to enter the passphrase twice section may leave /boot world-readable. (Note my installation -- maybe because of systemd-boot -- does not have a world-readable /boot, but a simple fresh grub & LUKS installation does.) In those cases, this means an unprivileged user can extract the initramfs, which has the keyfile in it. It doesn't matter that it extracts having 000 permissions, because it is owned by the extracting user. I propose adding to the section a recommendation to chmod 700 /boot, and add a warning phrased: "If /boot is left world-readable, an unprivileged user can access the keyfile within the initramfs." Note I talked privately with a security team member asking how to proceed on this, and he recommended posting here. Jamespharvey20 (talk) 08:08, 24 June 2019 (UTC)Reply

Hi, thanks for bringing this up, for the moment I've made a temporary fix.
This problem descends from [1] and [2].
The security issue that you describe has always been warned against in the linked Dm-crypt/Device encryption#With a keyfile embedded in the initramfs section, however the chmod 600 /boot/initramfs-linux* command was not duplicated in the new section, hence the problem.
I really think that Dm-crypt/Encrypting an entire system#Avoiding having to enter the passphrase twice should be merged back into Dm-crypt/Device encryption#With a keyfile embedded in the initramfs, and mostly just a link to it should be left.
About suggesting to chmod 700 /boot, as an alternative to chmod 600 /boot/initramfs-linux* (or a redundant measure), sounds good to me.
-- Kynikos (talk) 17:16, 25 June 2019 (UTC)Reply
Ahh, I see. I agree about the merge, and listing both permission changes as alternatives/redundancies. Jamespharvey20 (talk) 02:49, 26 June 2019 (UTC)Reply
Oops, I guess I missed the part about permissions when I rewrote the section.
I'm not particularly opposed to merging the sections, but I thought content duplication in dm-crypt/Encrypting an entire system was to be expected.
-- nl6720 (talk) 07:52, 26 June 2019 (UTC)Reply
Don't worry nl6720, missing one thing every hundreds of outstanding edits won't ruin your average :P
About duplication here, it's hard to define its boundaries, maybe we can say that this page is only meant to show how to use the various essential tools (whose detailed usage is explained in other articles) together to bring a system from zero to just booting into the desired configuration (and still as an integration to the Installation guide).
I think ideally post-first-boot extras, even if extremely recommended like the security fix above, should be generalized in other pages, although definitely linked to from here.
This definition may bind Dm-crypt/Encrypting an entire system#Encrypting logical volume /home and Dm-crypt/Encrypting an entire system#Post-installation to the same destiny as Dm-crypt/Encrypting an entire system#Avoiding having to enter the passphrase twice.
-- Kynikos (talk) 16:20, 26 June 2019 (UTC)Reply
mkinitcpio (since version 31 from 2021-11-29) creates initramfs images with 600 permissions so I remove the unneeded chmod command. -- nl6720 (talk) 05:53, 25 July 2024 (UTC)Reply


chmod 000 /root/cryptlvm.keyfile

Does 000 bring any extra securtity over 600 ?

Ua4000 (talk) 15:47, 10 March 2020 (UTC)Reply

According to https://unix.stackexchange.com/a/549471, to access 000 files, you need the DAC_OVERRIDE capability which is not guaranteed for daemons. I changed it to 600 to match dm-crypt/Device encryption#With a keyfile embedded in the initramfs. -- nl6720 (talk) 05:50, 25 July 2024 (UTC)Reply
It looks like you need to drop CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH for it to have effect. A quick test:
# echo test >/tmp/captest; chmod 000 /tmp/captest; capsh --drop=cap_dac_override,cap_dac_read_search -- -c 'cat /tmp/captest'
Assuming systemd-cryptsetup never drops these capabilities, it should be fine to use 000 for the keyfiles.
-- nl6720 (talk) 06:34, 25 July 2024 (UTC)Reply


Encrypted boot partition (GRUB)

The Disk layout in example is confusing, correct me if I'm wrong but I don't see any case where both an unencrypted BIOS boot partition AND an unencrypted EFI partition is needed. Maybe change it to have just sda1 (with Bios boot OR EFI partitions) and sda2 (luks + lvm) ?

—This unsigned comment is by Peapy (talk) 19:27, 8 January 2021‎. Please sign your posts with ~~~~!

--- kmille (Sat Dec 11 11:37:57 PM CET 2021): I think you are right. In addition, the `BIOS boot partition` (I'm not sure about the EFI stuff) should be `encrypted` and not `unencrypted`. That's the goal of "Encrypted boot partition (GRUB)" or do I miss something here?

The BIOS boot partition is not /boot. It is a partition where GRUB stores its bloat for BIOS booting from a GPT partitioned disk (on MBR partitioned disks it uses the post-MBR gap). None of the BIOS boot partition, EFI system partition or the post-MBR gap can be encrypted (except with SED, but that's out of scope here).
As for having both the BIOS boot partition and the EFI system partition on the same disk, yes that should not be very common. A use case for it would be Arch Linux on a removable medium.
-- nl6720 (talk) 16:20, 12 December 2021 (UTC)Reply

Simplified instructions for basic setup

For basic setup instructions could be a lot simpler. When using systemd-boot there's no need to create */etc/fstab* or to set kernel parameters as systemd-gpt-auto-generator will take care of it. The user just has to set partition types GUIDs when partitioning.

—This unsigned comment is by Danisztls (talk) 02:44, 26 February 2023. Please sign your posts with ~~~~!

Fstab may still be needed if using BtrFs with subvolumes since it doesn't seem to auto mount them. While you can mount the root subvol with rootflags=subvol=<path_to_subvol> kernel parameter, I'm not sure if you can mount other BtrFs subvolumes via kernel parameters with mount options etc Btrfs#Mounting_subvolumes. --Rendoe (talk) 02:09, 8 August 2023 (UTC)Reply

Include systemd-ukify in TPM2 and Secure Boot example for measured boot

The systemd-ukify tool allows to create UKIs that, when provided private and public PCR signing keys, can be used to measure various phases of the boot process into PCR 11. This increases security and it ensures the integrity of the platform that is being booted to than just the authenticity of it--enabling secure boot and binding to PCR 7.


To accomplish this, ukify will need to be used in-place of mkinitcpio for UKI generation. Also, an example of enrolling the TPM with systemd-cryptenroll will need to be done using --tpm2-public-key and --tpm2-public-key-pcrs to configure the PCR policy to bind the encryption to. Nu4425 (talk) 07:04, 14 October 2023 (UTC)Reply

Extend TPM2 and Secure Boot example with encrypted home directories

In the current example of Simple encrypted root with TPM2 and Secure Boot, the user's home directory is implicitly left unencrypted. This is a serious security hole and encryption should be employed via a service like systemd-homed. Doing so, significantly mitigates the risk of user's data being compromised in the event that their system is stolen and brings the overall security about-up-to parity with commercial devices like modern Chromebooks and Macbooks. Nu4425 (talk) 17:17, 14 October 2023 (UTC)Reply

Please have a look at dm-verity, wrt to be at parity with Chromebooks. For the example you reference in this article, a systemd-homed addition would be better but a compromise nonetheless. --Indigo (talk) 20:29, 14 October 2023 (UTC)Reply
Sorry, I retract my statement about being about-up-to parity like Chromebooks. Chromebooks was an example, and I think that there would need to be more changes to match their security model. In any case, all of them utilize a TPM or a similar device during the boot process and secure the' home directories separately.
Thanks for referring to the article of dm-verity and I think it's a good idea. However, it's a stretch to say that it's "a compromise nonetheless" than it is to say it would be incomplete or insufficient if comparing to Chromebooks.
Perhaps in addition to encrypted home directories, the example can include a component like dm-verity? Nu4425 (talk) 04:24, 15 October 2023 (UTC)Reply
Glad you appreciate the dm-verity article. I referred you to it, because I had the impression from your talk items that you had not seen it yet. IMO it would be overkill atm to reference it, particularly in the scenario we discuss here. I guess the scenario is most suited for stationary, single-user PC and a user who explicitly tries to avoid memorizing a strong LUKS passphrase. This does not mean some may choose a separate systemd-homed container, but it is one option. Changing partitioning layout for it makes the scenario unsuited for users it appears to address, adding a container doubles crypto overhead. How about adding a Tip to crosslink Systemd-homed as an option/risk mitigation for theft to it and let users decide?
--Indigo (talk) 13:29, 15 October 2023 (UTC)Reply
Hi. What exactly is this supposed mitigate against ? In the scenario, the disk is fully encrypted if taken out of the computer. If booted from the system, if Secure Boot is active and the user account has a decent password, how can a thief access any data at all ? The only way would be to extract the LUKS key from RAM, which to my knowledge is not something easily feasible by a common thief. If the threat is three letter agencies, I doubt an encrypted systemd-homed container by itself is a sufficient method anyway. Am I missing something ? -- Cvlc (talk) 15:21, 26 October 2023 (UTC)Reply
In this scenario, encryption is bound to the system's TPM2 device and it is used to automatically decrypt the user's encrypted root partition on boot. Since this process is non-interactive, the threat actor only needs to steal the user's device and power it on or wake it up to get the user's data--assuming the home directory is within the root. To mitigate this risk, encryption of the user's directory must be done in some way to guarantee confidentiality and the display/login manager does not ensure this. Of course, this assumes that the data the threat actor really cares about, as well as the user themself, is within the home directory. Also, whether it's practical or worth it to do this is left for debate, but it doesn't change the fact that this is a security hole in this scenario that is worth mentioning.
Alternatively, instead of encrypting the home directory in some way, the TPM2 device can be configured to unseal the keys only after providing a pin. Nu4425 (talk) 18:22, 29 October 2023 (UTC)Reply
I'm sorry but please explain "the threat actor only needs to steal the user's device and power it on or wake it up to get the user's data". How exactly does a threat actor do that without knowing a password which with which to log in ? Once the device is booted and sits at the "login : __" prompt, how can the data be accessed ? Cvlc (talk) 11:52, 2 November 2023 (UTC)Reply

LUKS on a partition with TPM2, Secure Boot, and PCR policies

Created a first dirty draft.

Works as-is but can be made simpler. Might add steps to enroll Secure boot keys with systemd-boot.

This should probably eventually replace the previous section, as I guess there is little benefit to using literal PCR values instead of signed PCR policies. Cvlc (talk) 22:18, 22 March 2024 (UTC)Reply

The Secure Boot part is inconsistent, needs a rework. Probably should not use ukify genkey for secure boot keys, but maybe leave it for sbctl or whatever one wants to use. Cvlc (talk) 23:27, 22 March 2024 (UTC)Reply
Re [3]: What's the pros/cons of adding your contribution as a separate scenario wrt to the existing TPM/SB section?
--Indigo (talk) 22:23, 24 March 2024 (UTC)Reply
Mostly, the only reason to use the former version is to keep using mkinitcpio only, instead of having to fiddle with kernel-install.
kernel-install works well but needs hooks from the AUR or to be manually configured, and is not as well known.
However, the scenario with PCR policies makes more sense I think in the long run, and maybe it simplifies things to only keep this example.
I'm trying to stick to the installation guide as much as possible, but also give a straightforward example of how to do it in "one shot", two requirements which don't go together so well jn that case.
Cvlc (talk) 00:01, 25 March 2024 (UTC)Reply
Ok, yes. Looking over related articles I could imagine your kernel-install section would serve well as a general example. For example, we have Unified kernel image#kernel-install to be merged and a general example could be under Kernel-install#Unified kernel images (section moved out of tips&tricks as a general example). If we had such an example in place, it may be relatively straight-forward to link it into the existing TPM/SB scenario in this article without making it overly complex.
After all an encrypted root is no prerequisite for a SB UKI config. It could be a regular/unencrypted root, dm-verity, or else. So, the benefit is larger.
What's your opinion on that?
--Indigo (talk) 21:57, 25 March 2024 (UTC)Reply

"Allows Full Disk Encryption" is misleading

dm-crypt/Encrypting an entire system#Overview says that the Plain dm-crypt scenario:

Allows Full Disk Encryption

And the scenario itself says:

Note that if full disk encryption is not required, the methods using LUKS...

IMO this is somewhat misleading since it unintentionally steers people looking for full disk encryption towards the plain dm-crypt scenario while the whole page is about full disk encryption. This is bad because as stated in section "2.4 What is the difference between "plain" and LUKS format?" of the cryptsetup FAQ:

First, unless you happen to understand the cryptographic background well, you should use LUKS. It does protect the user from a lot of common mistakes. Plain dm-crypt is for experts.

If the point is to not have any unencrypted partitions on the system, then in could be achieved in any other scenario too by simply placing the /boot partition on a USB flash drive. If the point is about the presence of the LUKS header, then it's about deniable encryption instead, so calling the advantage "full disk encryption", IMO, is not correct.

-- nl6720 (talk) 06:47, 24 August 2024 (UTC)Reply