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)
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  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'm undecided what we should do with this section. I see three alternatives:
- 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.
- We make it more elaborate and add a subsection per scenario at the end for it.
- 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)
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.
Recommend TRIM on non-FDE SSDs?
I came across SSDs Not Appropriate For Encryption?, and that's something I'd never considered: currently in Dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD) we're simply saying "Most users will still want to use TRIM on their encrypted SSDs", but implying that the only advantage is the performance gain. Shouldn't we instead strongly recommend to enable TRIM on SSDs that also store plain data, especially LUKS headers, for serious security implications? — Kynikos (talk) 11:45, 12 September 2015 (UTC)
- I see your point, but in my opinion (interested to learn others') a "one for all" recommendation is not useful. You can indeed never be certain how a particular SSD behaves, but the LUKS header is designed "to be laying around". The only scenario a TRIM may help out is when you change a passphrase because it got/may be compromised but you know for certain the attacker has had no read-access to the device (i.e. copy the luks header before passphrase change). If you want to phrase the point in at the end of the first para, please do! To keep in mind is that an "un-trimmed header attack vector" implies the SSD is searched in total, because the attacker has no clue where (and if at all) the SSD firmware may have left behind an old header in spare sectors during cow.
- Something related I have had in mind for some time is a subsection on the encryption subpage for cryptsetup-reencrypt of an existing partition. I deliberately waited because the operation is delicate. Though, the feature has been available (marked experimental) a long time now. I believe in most cases by far when a user feels the necessity to change a passphrase/key for blockdevice encryption, the risk that a copy of the luks header has been obtained is there anyway. If in doubt, a clean re-encryption is always the better choice then. --Indigo (talk) 18:10, 12 September 2015 (UTC)
- Thanks Indigo, this is what I've done for the moment, how do you like it?
- Actually I was also dreaming of writing a centralized section somewhere on the security of SSDs, since information is a bit scattered at the moment among at least Dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD), Solid State Drives, SSD memory cell clearing and Securely wipe disk#Flash memory.
- It would be awesome if you wrote something about cryptsetup-reencrypt! Template:Warning is very good at marking experimental software.
- — Kynikos (talk) 05:31, 13 September 2015 (UTC) (Last edit: 07:52, 13 September 2015 (UTC))
- Yes, great job!
- For an "SSD security" article: I'm not sure really. The current split up of content is not bad. If something is a bit odd placed, it is the section here (maybe it should have better be placed in Dm-crypt/System configuration right away .. I remember we discussed it back then). I think it would be better to create a Solid State Drives#Security subsection, use the section intro to crosslink relevant content with some bullets (your links above) and move some of the related items under it (Solid_State_Drives#Hdparm_shows_.22frozen.22_state and Solid State Drives#SSD Memory Cell Clearing). A separate article may tear too much info from the other articles. --Indigo (talk) 13:48, 13 September 2015 (UTC)
- Now did create an initial SSD Security section with . The point with the bullets from above did not seem necessary so far (the subsections link out themselves), so it was briefer than anticipated. What we discuss in this item (TRIM) could be mentioned, but in general the TRIM content is more performance than security oriented and for dm-crypt readers land here anyway. Do you see any points missing?
- Also added Dm-crypt/Device encryption#Re-encrypting devices today. I know it got a tidbit long, if there are ideas to shorten it, please do. --Indigo (talk) 14:44, 17 September 2015 (UTC)
- Read through this item again, I believe it is covered. Closing therefore. --Indigo (talk) 08:22, 1 June 2016 (UTC)
- 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)