Slackware full disk encryption questions

tramtrist · 03-18-2021, 12:47 PM

I've always used this guide https://blog.darknedgy.net/technology/2014/07/27/1/ appended with the fstrim options in cryptsetup found in another thread on the forum.

kmreiserfs · 03-18-2021, 03:54 PM

I have my slackware /root encrypted but the /boot is out

/dev/nvme0n1p3 1833951232 1836048383 2097152 1G Linux sistema de arquivos (boot)
/dev/nvme0n1p4 1836048384 2000409230 164360847 78.4G Linux LVM (root LUKS)

Using grub2

Make sure to make the initrd to enable luks on boot.

/usr/share/mkinitrd/mkinitrd_command_generator.sh

Everything was done using slackware official docs https://docs.slackware.com/

Linux.tar.gz · 03-29-2021, 03:31 PM

Thanks everybody for your comments.

So here's a quick'n dirty howto for both / and /boot encrypted Slackware64-current.
Only tested under Qemu 5.1.0 with a 10G disk img.
As is, it won't work on a UEFI-only computer.
Reviews and comments welcome.

/boot is luks1.

You can test that install using only those three packages set: a/ ap/ l/

#Non-EFI
#GPT
#GRUB (+GPT) -> BIOS BOOT partition
#Encrypted / and /boot

grub-2.04-x86_64-3 will not work !!! You will get a grub-install: error: Decompressor is too big
Use an older grub-2.04-x86_64-2 or even grub-2.04-x86_64-1 that you will install after the setup without reboot

Code:

cfdisk /dev/sda

sda1, 500M (too much ! 1M should be enough) BIOS BOOT
sda2, 500M /boot
sda3, remaining space for lvm

Code:

dd if=/dev/urandom of=/dev/sda2
cryptsetup -s 256 -y luksFormat --type luks1 /dev/sda2

Code:

cryptsetup luksOpen /dev/sda2 lukssda2

//not needed for a single partition, but probably doable
//pvcreate /dev/mapper/lukssda2
//vgcreate cryptvgboot /dev/mapper/lukssda2
//lvcreate -l100%FREE -n boot cryptvgboot

Code:

dd if=/dev/urandom of=/dev/sda3
cryptsetup -s 256 -y luksFormat /dev/sda3

Code:

cryptsetup luksOpen /dev/sda3 lukssda3

Code:

pvcreate /dev/mapper/lukssda3
vgcreate cryptvg /dev/mapper/lukssda3
lvcreate -L 8G -n root cryptvg
lvcreate -L 100M -n swap cryptvg
lvcreate -l100%FREE -n home cryptvg
mkswap /dev/cryptvg/swap

Code:

setup

cryptvg-root as /
cryptvg-home as /home
/dev/mapper/lukssda2 as /boot

Skip lilo install.
Don't reboot !
Copy the old grub package into /mnt

Code:

chroot /mnt
removepkg grub
installpkg the_old_grub_package

Code:

cat /etc/fstab
/dev/mapper/cryptvg-root on / type ext4 (rw,relatime)
/dev/mapper/cryptvg-home on /home type ext4 (rw,relatime)
/dev/mapper/lukssda2 on /boot type ext4 (rw,relatime)

Code:

cd /boot
mkinitrd -c -k 5.10.26 -m ext4 -f ext4 -r /dev/cryptvg/root -C /dev/sda3 -L
//or for french keyboard
//mkinitrd -c -k 5.10.26 -m ext4 -f ext4 -r /dev/cryptvg/root -C /dev/sda3 -L -l fr

Code:

vim /etc/default/grub
GRUB_ENABLE_CRYPTODISK=y

If you use a ssd, read that before applying the code below:
https://wiki.archlinux.org/index.php...e_drives_(SSD)
https://wiki.gentoo.org/wiki/Full_Di...ied#SSD_tricks

Code:

vim /etc/default/grub
GRUB_CMDLINE_LINUX="root_trim=yes"

vim /etc/lvm/lvm.conf
issue_discards = 1

"When using SSDs and UEFI-boot the boot sequence might be too fast. When entering the correct passphrase Kernel complains about missing modules or no root device. Try rootdelay=3 added with GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub or directly append it in edit mode of Grub menu when booting"

Code:

grub-install /dev/sda
//seems not needed
//grub-install --modules=part_gpt /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

Code:

exit
halt

Pass are needed for /boot (grub), then / .
After boot, you'll notice that /boot isn't mounted. Open the luks then "mount -a" if you plan to update the kernel or grub settings.
Don't forget to blacklist grub in slackpkg !

I have trouble with nano, ctrl-x to quit don't work with this encrypted setup !!!

Any insight about avoiding typing the / password and also automounting /boot is welcome.

Didier Spaier · 03-29-2021, 05:24 PM

Quote:

Originally Posted by Linux.tar.gz

Any insight about avoiding typing the / password and also automounting /boot is welcome.

Put a LUKS key in the initramfs
Install a LUKS key (for instance in a directory named /etc/keys) for each encrypted partition you want to boot. This key will be registered in a line of the file /etc/crypttab.

Note that 1. needs to modify the script init shipped in the mkinitrd source. You can do that rebuilding the mkinitrd package applying the attached patch.

Indeed when installing a new package you'll have to include again the master LUKS key (also stored in /etc/keys) in the new initrd.

I attach to this post the aforementioned patch and also the script 'auto' which, during Slint installation, does all that's needed to have a full disk encryption if requested. Have a look at the functions encryptthedrive, installkeyfile, crypttab, attached and portable to know how it's done.

Caveat: our layout includes neither a separate /boot partition nor LVM, only a BIOS Boot partition, an ESP (both non encrypted) / (encrypted) and optionally and additional partition to store miscellaneous data (encrypted).

Linux.tar.gz · 03-31-2021, 03:40 PM

Isn't there some way for grub to invisibly append the first password to the kernel command line or something like that ?

Btw, is it unsecure to use the same password for multiple encrypted partitions ?

Didier Spaier · 03-31-2021, 04:33 PM

Quote:

Originally Posted by Linux.tar.gz

Isn't there some way for grub to invisibly append the first password to the kernel command line or something like that ?

No, as far as I know.

mralk3 · 03-31-2021, 09:54 PM

Quote:

Originally Posted by Linux.tar.gz

Btw, is it unsecure to use the same password for multiple encrypted partitions ?

It sort of defeats the purpose of having separate encrypted parititions. Why not just make it one partition, with one password? Same difference. Ideally you want to have separate, alpha numeric, 8+ character passwords. 8+ characters makes it much harder than 7 or less. I speak from past experience testing WiFi, network logins, encrypted pdfs, etc. Of course this testing was done on my systems, on my own network, with my own accounts and software. Password reuse is worse than having a different weak password for every partition.

Linux.tar.gz · 04-01-2021, 04:50 PM

Quote:

Originally Posted by mralk3

Why not just make it one partition, with one password?

I'd like to have an encrypted /boot .

gargamel · 04-02-2021, 12:32 PM

tl;dr. This is just for confirmation that two passwords are needed (could be the same password taking all the risks outlined by mralk3).

I have yet to try it on Slackware, but recently I installed an OpenSUSE system with full disk encryption. It was easy to do, but I have run in to the exact same issue: I am asked twice for a passphrase, once for /boot and a second time for the root partition. OpenSUSE uses Grub by default.

Question: On a UEFI install, wouldn't it be good enough to have an unencrypted EFI partition, instead of leaving /boot unencrypted as a whole? That would make it a little easier to detect intruders, as you always could compare the binaries in /boot with those on EFI. If they differ, you might have forgotten to copy your recently updated kernel binary or initial RAM disk over, or the files on either side may have been tampered with.

gargamel

Linux.tar.gz · 04-02-2021, 04:06 PM

My feeling is that when the device is UEFI-only (legacy BIOS is unavailable), you're screwed because you're forced to use "secure" boot to achieve a satisfying level of security.
I don't trust the way UEFI works, there's way too much code inside (far more than the Linux kernel AFAIK).

gargamel · 04-02-2021, 06:18 PM

Well, UEFI install doesn't mean UEFI only system, actually. All my current systems use UEFI, but without secure boot.
So I guess that with "UEFI-only" you mean no CSM, actually, right?

Linux.tar.gz · 04-04-2021, 02:24 AM

Never heard of CSM before your post probably because I mostly use "old" hardware, but something like that yes.

Linux.tar.gz · 06-09-2021, 05:14 PM

a/grub-2.06-x86_64-1.txz: Upgraded.

Does anybody know if the aforementioned problem is solved ?

Linux.tar.gz · 04-04-2022, 12:57 PM

Quote:

Originally Posted by Linux.tar.gz

a/grub-2.06-x86_64-1.txz: Upgraded.

Does anybody know if the aforementioned problem is solved ?

Looks like it's solved with 15.0 64 bits.

Didier Spaier · 04-04-2022, 02:23 PM

[content already posted, so removed from this post.]