Full Disk Encryption WITHOUT Initramfs or Grub

[pietinger]

How to (Secure-) Boot the kernel straight from UEFI(-bios) into a fully encrypted root-partition with plain dm-crypt encryption without using initramfs/initrd or grub. This was not possible so far. Now we have the new kernel(-module) parameter "dm-mod.create=" (dm_init).

Objective:
* Secure using the new parameter for built-in dm-crypt-functionality
* With a SSD it must not happen to save the masterkey into a file on it (even with a hd you cant really wipe a file when using a journaled filesystem). This means it is required to save the masterkey into RAM (=tmpfs) or to a stick. (I used a stick because we have to save the key in any case).

I have:
* A working Gentoo Installation on /dev/sda4 as root (containing home also) with a monolithic (signed) stub-kernel in /boot/EFI/Boot (/dev/sda2)
* An empty partition (/dev/sda5) for my new fully encrypted root partition
* An USB-Stick for the final kernel (and the masterkey if no second stick available)
You:
* MUST have openRC; (I dont know anything about systemd)
* needn't have a monolithic signed kernel; just a working kernel

Here is my course of action:

[msst]

This sounds interesting, but is there an option to get this going via a password prompt, using dm-crypt luks?

Currently I use such a setup with an initramfs.

[pietinger]

[Hu]

Prompting for a login password is too late. The drive has already been unlocked, and the only thing protecting it is that the system is hopefully not compliant until a password is entered. However, I don't see anything in your instructions to prevent an attacker simply adding init=/bin/sh to the kernel's command line, and then bypassing the getty challenge entirely.

The security of this method appears to turn entirely on preventing an attacker from obtaining a copy of the kernel, since the kernel can and will boot to an unlocked state without user intervention. Systems built around requiring a user password to unlock a LUKS volume turn on the quality of the user's LUKS password.

[msst]

[axl]

[alamahant]

What is the benefit in general of not using an initramfs?
Is it faster booting?
Thanks

[tbart]

Well, i mostly do the same (no grub, booting from EFI directly) but with an initramfs.
But this initramfs is included in the kernel, so I don't need any unencrypted partition (except the EFI one which you need anyway) on my disk.
The whole disk is LUKS encrypted using a password, no key or plaintext password for data partitions needed. If you like, use a USB stick. Or whatever scheme LUKS supports.

The build process is streamlined using a little script that does all that's necessary (building kernel, initramfs, including it into the kernel, copying it to the efi partition, updating boot entries)

Regarding speed:
Is 12s (excluding password input) to graphical login fast enough (this is a notebook, not a high end workstation/server)?

I like the flexibility of having an initramfs to e.g. include an SSH server or other stuff, should I ever need it, and frankly, a mere 20M kernel size is OK for me! Mounting a LUKS volume in another PC or recovery environment also seems easier to me...

[axl]

USB stick is a good solution. As long as you don't leave it hanging around to be stolen.

pxe (tftp/dhcp) boot also works ok. I prefer this solution. The tftp server which has/holds the kernels/initramfs files/key files is a small raspberry pi I keep secured and offline and under locking key. I only connect it to the switch when I need to reboot something or update a kernel. Connect it, update, boot, disconnect.

EDIT: the reason I had to resort to this solution is because some of my systems are headless. None the less, even so, the key is not always bundled on the tftp server. I use that design for 1 of the servers, but not the others. I have to manually ssh (within the initramfs) to unlock the disk manually with password and then let the boot continue. I feel the last of the solutions is most secure, but kinda inconvenient. Not sure how I will move forward with these, but never the less I feel pxe booting allows for some flexibility.

[Hu]

[axl]

Even if firmware is locked, you could still move the drive to a system where the firmware is not locked. Or you could reset the firmware. Remove the battery. Remove the drive.

I think, most types of bios/firmware, even if locked with password, even if boot options have been limited (i.e. only boot from this disk), will try to boot other medium regardless. NOT ALL, but some. I tried. Set up boot... only boot this thing, remove that thing, and add another thing. Bios says... ohhh that thing is gone, maybe I'll try this other thing. And this is why I don't like USB devices.

What I learned in the past few years is that you can't trust manufacturers to do a proper firmware. On the other hand, if things were done properly, I would have been locked out of my systems several times over the last decade.

Anyway, thanks for that clarification. Now I'm curious how many of my systems actually implemented a full efi shell. Thanks for giving me something to do

[pietinger]

[storopoli]

Dear @pietinger,

Thank you for the detailed guide.
I am having issues trying to do this in my laptop that has a NVMe instead of SSD.
The root partition is /dev/nvme0n1p3:

[pietinger]

Dear storopoli,

first of all: I havent tested it with btrfs (because I dont use it), but it should work with btrfs because dmcrypt is a layer below these filesystems. dmcrypt must know which partiton (of block device) is has to use and therefore needs major and minor number of it (and sorry for my poor english).

[NeddySeagoon]

pietinger,

dm-mod.create= does work, I use it because I'm lazy. :)
I really need to create an initrd.

It's very fragile. If the size of the logical volume changes, the dm-mod.create= entry on the kernel command line needs to change or the the box will be unbootable.
It can describe a logical volume spanning several disjoint extents. The idea of keeping it up to date makes my head hurt.

device-mapper is not at all happy about finding one logical volume is use when it tries to start the rest either ... but it works.

[storopoli]

So that means that with NVMe, i.e. block 259, the device minor is not guaranteed to have the same number, so this creates boot problems?
I don't have a USB stick to test it right now.

[pietinger]

[NeddySeagoon]

pietinger,

I'm aware. My first brush with dm-mod.create is documented on the Wiki
I was trying to do root in lvm on top of raid5 with no initrd, but the kernel tries to create the device mapper volume before the raid set is started, so that was 'game over'.

Today my main system has a boot entry

[pietinger]

[NeddySeagoon]

pietinger,

"linear" refers to the on disk data layout of the logical volume.
See Early creation of mapped devices

That link calls it "target_type".

By keeping the /boot separate from the encrypted system, security is improved, until they are both lost together. Then it no better than an unencrypted system.

Its still fragile for the reasons I've mentioned, so I don't recommend this solution.
Just like I don't recommend other things that i do :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pietinger]

[pietinger]

Neddy,

this thread is also - like your article - more a "proof-of-concept". Yes, there is a better solution than FDE (full disk encryption) and I dont recommend FDE in my german guide.

Maybe I should be more detailed in my thinkings about computer security (like I described in my german guide):

You have two kind of threats:
1. Online attack (via network; also via "special" crafted files you get, like mp4,pdf, mails, ...) and
2. Offline tampering (someone installs "evil" software/hardware on/in your computer)

It is obvious that a "full disk encryption" only protects you against offline tampering and NOT against online attacks. So ... what happens if you lose your notebook (or it was stolen) ? Do you ever get back your notebook ? Usually no. If your notebook is gone you have no influence what will be done with it (maybe it will be completly disassembled; who cares) ... your only wish is: It is impossible to read your personal data. So, ask yourself: Do I really need to protect against (2) ?

If NO: To protect your personal data if your notebook is stolen an encrypted /home is quite sufficient. For this solution I recommend "fscrypt".

If YES:

a) If you really think someone will break into your hardware, then you will have no chance against professionals -> "They" install a hidden hardware key logger ... (secrect services do this) ... so please forget it ... there is no security against these kind of threat.

b) If you want protection against not so professionals, there is a better solution than FDE: Use an exchangeable harddisk ! Yes, there exists also exchangeable SSDs ... shutdown your system before going home, and take this SSD home. Then take your exchangeable SSD and put it into your safe (instead an usb stick).


(Personal I dont have any encrypted data on my desktop and my notebook is using "fscrypt"; because I am more afraid with online attacks than offline tampering, and therefore using this solutions: hardened kernel, apparmor, IMA and firewall)

[X4DE]

[pietinger]

X4DE,

Welcome to Gentoo Forums !

[X4DE]