Difference between revisions of "Talk:Dm-crypt/Encrypting an entire system"

From ArchWiki
Jump to: navigation, search
(Merging plain dm-crypt instructions with LUKS instructions)
(Btrfs on LUKS: Add rootflags=subvol=@ to kernel command line?: re, close)
 
(166 intermediate revisions by 25 users not shown)
Line 1: Line 1:
== Merging plain dm-crypt instructions with LUKS instructions ==
+
== LUKS on LVM /tmp example ==
  
I just noticed that the instructions are fairly similar for encrypting a system with LUKS and without. LUKS is just a header at the beginning of the device or partition that dm-crypt is created on; it doesn't change the device mapper configuration or partition layout in any way. Encryption on LVM and LVM on encryption definitely need separate instructions because they are very different setups, but whether or not LUKS is involved really only affects one command in the entire tutorial:
+
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. [[User:TravisE|TravisE]] ([[User talk: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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)
 +
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]
 +
: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?
 +
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)
  
Without LUKS:
+
== Encrypted boot (GRUB): no need for separate partition? ==
# cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc
 
With LUKS:
 
# cryptsetup luksFormat /dev/sdx3
 
  
Other than that, the procedure is the same, is it not? We would still need to discuss what LUKS is and whether or not to use it ([[Dm-crypt/Encrypting_an_entire_system#Setup_encryption]] should remain, and could be moved to the top of the article, for example), but I don't think we need completely separate instructions for LUKS and plain dm-crypt. In the few cases where the setup procedure does differ, we could make a small note about what to do if using plain dm-crypt). For example, we could add this to the "Preparing the disk" sections:
+
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:
{{Note|If you are using plain dm-crypt, it is recommended that you fill the mapped device before continuing. See [[Dm-crypt/Drive_Preparation#dm-crypt_specific_methods]] for instructions.}}
 
  
Nearly all the other steps -- including dedicated /boot partition preparation, LVM setup, mkinitcpio hooks, and bootloader installation -- are identical whether LUKS is used or not. In fact, the current layout seems more cumbersome, as [[Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt]] currently forks its instructions at certain points based on the decision of LVM on encryption vs encryption on LVM. It seems that it should be the other way around (LVM on encryption / Encryption on LVM sections should fork based on LUKS vs plain, as the latter pair are far more similar to each other.
+
+---------------+----------------+----------------+----------------+----------------+
 +
|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      |----------------+----------------+----------------+----------------+
 +
|'''un'''encrypted    |/dev/sdaY encrypted using LVM on LUKS                             |
 +
+---------------+----------------+--------------------------------------------------+
  
Notice I imply changing the word "LUKS" to "encryption", as it could imply LUKS or plain dm-crypt interchangeably. Of course, LUKS is still the much more common use case of the two (in fact, the [[https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions|dm-crypt FAQ]] doesn't really recommend plain dm-crypt at all.)
+
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.
  
Without looking at the edit history, I would guess the reason they are currently separate is a relic of merging [[Dm-crypt with LUKS]] and [[Plain dm-crypt without LUKS]] into this page. I don't really have any experience with plain dm-crypt, to be honest, so I could be wrong about this, and I wanted to ask for some other opinions before I go making drastic changes. [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 21:19, 10 December 2013 (UTC)
+
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.
  
:Let's go step by step, don't do too much merging at the same time (also considering our [[Help:Style#Edit summary|rule]] to do several little edits instead of a few big ones). First I'd say let's reorganize [[Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt]] to make it look as similar as possible to the other scenarios. Then we can assess the possibility of merging it to the LUKS scenario. However note that they don't have the same kernel parameter (boot loader) configuration, as you instead wrote. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:32, 11 December 2013 (UTC)
+
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.
  
::Sounds good to me [[User:Kynikos]]. I just wanted to make note of it and have the possibility considered at some point. As far as the kernel boot parameter, I think you're referring to
+
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)
:: {{ic|1=crypto=<hash>:<cipher>:<keysize>:<offset>:<skip>}}
+
 
::which is required with plain dm-crypt, in addition to {{ic|1=cryptdevice=}}. I did forget to mention that, since LUKS stores that information in the header. I'm not saying that the setup procedures for plain dm-crypt and dm-crypt with LUKS are identical, just that they are probably similar enough to be part of the same tutorial, with a few "If you are using plain dm-crypt..." notes here and there. At any rate, we can focus on that after [[Dm-crypt]] is figured out, as you suggested. [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 15:09, 11 December 2013 (UTC)
+
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==
:::+1 to step-by-step. Though, I'd state my opinion right away that merging will make our ''simple'' first scenario (intended for the average laptop user with simple partitioning requirements) more complicated than necessary. The plain scenario ''needs'' crypto and an usb-key, LUKS not.
+
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.
:::Cutting the plain example down to its original example (ie. not the plain defaults) intent should keep it an interesting howto for those who require or want plain attributes (and read down the page). Sidenote: A conditional "if" ''in'' the plain dm-crypt scenario could be placed too:
+
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/
:::{{Note|If you have a requirement for a blockdevice without a cryptheader but want to use LUKS instead of plain mode, consider placing the header remote on an usb-key with the {{ic|--header}} option.}}
+
 
:::Just suggesting we might reach both audiences better this way;) --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:18, 11 December 2013 (UTC)
+
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)
::::"The plain scenario needs crypto and an usb-key, LUKS not." I'm not exactly sure what you mean. Yes, plain dm-crypt does require cryptsetup options defining the type of crypto, whereas LUKS does not. How does plain dm-crypt require a USB drive in a way that LUKS doesn't? They both need an unencrypted /boot device; that's not dependent on plain versus LUKS. The exact ''cryptsetup'' commands will differ depending on plain versus LUKS, but the semantics are the same. We can leave the "simple" scenario alone for the sake of keeping it simple.
+
 
::::I like the {{ic|--header}} idea. I didn't realize such an option existed, and it might have some interesting use cases. It's probably worth mentioning. [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 23:03, 11 December 2013 (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)
:::::I should have wrote plain needs an usb-key ''more''. I was referring to the scenario employing the usb-/boot for a number of security reasons which are more desirable/important if using plain. Nonetheless, the example scenario (with usb keys) still gives a howto for the usb-part which readers can apply to the other scenarios. First scenario simple, then different specialties in the others, stating in the intro that mix&match should be done for the individual case. Makes sense? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:03, 12 December 2013 (UTC)
+
 
::::::I see what you mean. We could probably just link to [[Dm-crypt/Specialties#Securing_the_unencrypted_boot_partition]] for that, right? I'm in agreement about mixing and matching individual cases, but does this mean you'd rather keep LUKS and plain separate, or merge them together? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 04:14, 14 December 2013 (UTC)
+
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)
:::::::I'd keep them separate. All of the sections we have on this subpage for ''one'' install scenario as simple as possible. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:37, 14 December 2013 (UTC)
+
::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.
 +
::— [[User:Kynikos|Kynikos]] ([[User talk: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
 +
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)
 +
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)
 +
 
 +
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example
 +
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)
 +
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk: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 :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)
 +
 
 +
== <s>Btrfs on LUKS: Add rootflags=subvol=@ to kernel command line?</s> ==
 +
In [[Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader_7]], I think there should be a note that one needs "rootflags=subvol=@" or similar as kernel parameter? Not sure about it, going to test it soon.
 +
 
 +
The only mention of rootflags= and btrfs together seems to be in [[Btrfs#Booting_into_snapshots]]
 +
[[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:07, 30 September 2017 (UTC)
 +
 
 +
:An alternative would be [[Btrfs#Changing_the_default_sub-volume]]
 +
:[[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:25, 30 September 2017 (UTC)
 +
 
 +
:It's not necessary to add that to your kernel line. I have a subvol named `@` for my root and have not needed to do that.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 20:55, 30 September 2017 (UTC)
 +
 
 +
:Just as a note, I am using GRUB. "grub-mkconfig" properly populates grub.cfg with "rootflags=subvol=@" with no intervention needed by me. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 21:02, 30 September 2017 (UTC)
 +
 
 +
:: Without setting it as default subvolume via "btrfs subvolume set-default"? (You can check with "btrfs subvolume get-default <path>") Thanks.
 +
::[[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 21:05, 30 September 2017 (UTC)
 +
 
 +
:::Right. I have not changed the default subvolume:
 +
 
 +
    # btrfs subvolume get-default /
 +
    ID 5 (FS_TREE)
 +
 
 +
:::Have you tried booting without adding the flag manually? {{Unsigned|15:47, 2 October 2017|Rdeckard}}
 +
 
 +
::::No, but I hope I will be able to test it soon. I don't have a Btrfs setup right now. I proposed this change only because it seemed necessary to me from what I've read... It seems GRUB detects the root partition automatically then, like you wrote. Thanks for you answer. [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 17:39, 2 October 2017 (UTC)
 +
 
 +
:::::Sounds good. Closing. Re-open if you have an issue. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:30, 6 October 2017 (UTC)

Latest revision as of 14:30, 6 October 2017

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)

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)

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)

Btrfs on LUKS: Add rootflags=subvol=@ to kernel command line?

In Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader_7, I think there should be a note that one needs "rootflags=subvol=@" or similar as kernel parameter? Not sure about it, going to test it soon.

The only mention of rootflags= and btrfs together seems to be in Btrfs#Booting_into_snapshots Mearon (talk) 20:07, 30 September 2017 (UTC)

An alternative would be Btrfs#Changing_the_default_sub-volume
Mearon (talk) 20:25, 30 September 2017 (UTC)
It's not necessary to add that to your kernel line. I have a subvol named `@` for my root and have not needed to do that. -- Rdeckard (talk) 20:55, 30 September 2017 (UTC)
Just as a note, I am using GRUB. "grub-mkconfig" properly populates grub.cfg with "rootflags=subvol=@" with no intervention needed by me. -- Rdeckard (talk) 21:02, 30 September 2017 (UTC)
Without setting it as default subvolume via "btrfs subvolume set-default"? (You can check with "btrfs subvolume get-default <path>") Thanks.
Mearon (talk) 21:05, 30 September 2017 (UTC)
Right. I have not changed the default subvolume:
   # btrfs subvolume get-default /
   ID 5 (FS_TREE)
Have you tried booting without adding the flag manually? —This unsigned comment is by Rdeckard (talk) 15:47, 2 October 2017. Please sign your posts with ~~~~!
No, but I hope I will be able to test it soon. I don't have a Btrfs setup right now. I proposed this change only because it seemed necessary to me from what I've read... It seems GRUB detects the root partition automatically then, like you wrote. Thanks for you answer. Mearon (talk) 17:39, 2 October 2017 (UTC)
Sounds good. Closing. Re-open if you have an issue. -- Rdeckard (talk) 14:30, 6 October 2017 (UTC)