Talk:Dm-crypt/Encrypting an entire system

From ArchWiki
Jump to navigation Jump to search

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: [1]
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)

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)

You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.
--Elijah Master (talk) 18:03, 6 December 2017 (UTC)
The section now uses a combination of LUKS and LUKS2 encrypted volumes, so simplifying the setup would require forfeiting the use of LUKS2. Example partition layout:
| BIOS boot partition | EFI system partition | Logical volume 1     | Logical volume 2     | Logical volume 3     |
|                     |                      |                      |                      |                      |
|                     | /efi                 | /                    | [SWAP]               | /home                |
|                     |                      |                      |                      |                      |
|                     |                      | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |
| /dev/sda1           | /dev/sda2            +----------------------+----------------------+----------------------+
| unencrypted         | unencrypted          | /dev/sda3 encrypted using LVM on LUKS                              |
-- nl6720 (talk) 13:13, 23 November 2018 (UTC)
dm-crypt/Encrypting an entire system#LUKS on software RAID and dm-crypt/Encrypting an entire system#Btrfs subvolumes with swap also use LUKS1, so I guess it's not considered an issue. If no one stops me soon, I'll remove the separate /boot partition from Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB). -- nl6720 (talk) 13:21, 6 January 2019 (UTC)
Done. -- nl6720 (talk) 10:05, 10 January 2019 (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.

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)

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)
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)
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)
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)
How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- nl6720 (talk) 09:44, 18 April 2018 (UTC)
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)
'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)
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)
From these, I'd vote for "MyVolGroup". -- nl6720 (talk) 16:17, 20 April 2018 (UTC)
"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)
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)
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)
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)
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)
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)

/boot Needs to remain unencrypted fallacy

I think that we should create an additional section, showing that IT IS POSSIBLE using BIOS mode to create a true full disk encryption and stop spreading this misinformation that /boot needs to remain unencrypted, like this tutorial: -- Risthel (talk) 13:57, 1 October 2018 (UTC)

You mean ? And you don’t need BIOS mode. You can even use SecureBoot to sign your GRUB uefi with your own keys. Archange (talk) 09:00, 2 October 2018 (UTC)
Your linked setup will still not be a "true full disk encryption". The GRUB in MBR and MBR-gap or BIOS boot partition will remain unencrypted. -- nl6720 (talk) 09:23, 2 October 2018 (UTC)
2 Things here: 1 - This Encrypted boot partition with EFI will still need an unencrypted EFI(thus, susceptible to EFI malware/tampering) ; 2 - SecureBoot customization is hardware dependent. Some machines will not allow you to inject your own keys, having to rely on Microsoft signing or disabling it at all. When i say that it IS possible using BIOS, i'm not saying its not possible through EFI. But it is better showing the way /boot CAN be encrypted on BIOS mode instead of making this lie go further that /boot NEEDS do be unencrypted on BIOS environment :) . I'm also aware of MBR not being encrypted, and maybe a "hook" could be developed where mkinitcpio could check grub's hash with a file stored at /boot or root partition and alert the user... but that is offtopic and should be part of other wiki :) -- Risthel (talk) 18:01, 2 October 2018 (UTC)
But unencrypted MBR is just the BIOS equivalent to unencrypted EFI. So what your saying makes no sense. Just like you could check grub hash, you could check grub efi hash. And they are already software for that. The easiest and most secure (tells you before entering your password) is still using SecureBoot/TPM, or using an EFI/grub on a USB device. Or both. Archange (talk) 18:32, 2 October 2018 (UTC)
Agree with you. To make it complete in BIOS and minimize evil-maid attacks trustedgrub(aur)[2] should be used. But again, it's still a lie to say at the wiki that "/boot must be unencrypted" -
You do realize that dm-crypt/Encrypting an entire system#Preparing_the_boot_partition_2 is in the dm-crypt/Encrypting an entire system#LVM on LUKS scenario? Encrypted /boot is described separately in dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB). -- nl6720 (talk) 05:57, 3 October 2018 (UTC)

Why the ASCII diagrams?

Why do you people make those ASCII diagrams for this page? Would using those nice Unicode symbols (╠═╬═╣║) not be better? And using MediaWiki tables even better?

BTW, here's a nice Web site which can generate all of those formats of table descriptions: Neven (talk) 13:04, 6 January 2019 (UTC)

AFAIK tables are not used due to accessibility issues. -- nl6720 (talk) 13:24, 6 January 2019 (UTC)
Some diagrams on this page have multiple different vertical alignments in the same cell. Good luck realizing that with HTML. Also we prefer our wikicode to be editable without external tools and mutlirows / multicols are very cumbersome to work with by hand. --Larivact (talk) 19:50, 7 January 2019 (UTC)

Regarding the attempted fixing of ASCII table alignment failure: I realize that your revertion of my fixes (conditionally speaking) aligned the rows assuming a fixed-width typeface, but on Chromium 71.0.3578.98 (and whatever versions of relevant libraries), a proportional typeface is used. Namely, "ef" takes up the same space as " " does, I think. I think the correct term for that is "ligature".

Anyway, I think this just shows those character-based tables should be abandoned in favor of using MediaWiki tables. Neven (talk) 18:02, 7 January 2019 (UTC)

Your fonts must be misconfigured it looks fine in my Chromium. Do the following lines have the same length for you?
Does the right side of [3] look monospace to you? --Larivact (talk) 19:32, 7 January 2019 (UTC)
The 10 'f' characters are combined into 5 pairs of ligatured "ff", one ligature takes takes as much space as one 'W'. So the 10 'f' characters take as much space and line up with 5 'W' characters.
That tryit text you linked is monospace except that "fi" in "fixed" are joined in a ligature. Neven (talk) 21:43, 7 January 2019 (UTC)
Here is a Archlinux BBS thread which explains the issue if anybody is curious: [4], I also have "Nimbus Mono PS" as the default monospace font, and it supports ligatures.
This explains how to try to disable the ligatures: Font_configuration/Examples#Disable_ligatures_for_monospaced_fonts
Even if it is possible to configure Chromium to disable ligatures (have not checked), I still think this is a big argument against using ASCII art in the wiki. Neven (talk) 22:35, 7 January 2019 (UTC)
AFAIK we used the current ASCII form, because the same format was used in related (LVM,RAID) articles and was the default output of at the same time.
When trying alternatives a good way to check accessibility is if you try that your example, e.g.
looks like an improvement to the existing
Consider users install purely in TTY & elinks is included in the ISO.
--Indigo (talk) 17:36, 11 January 2019 (UTC)

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)

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