Kernel lockdown in 4.17?

Posted Apr 3, 2018 14:45 UTC (Tue) by ju3Ceemi (subscriber, #102464)
Parent article: Kernel lockdown in 4.17?

I do not see this as a dump feature
However, I do see this as an ultra-niche feature, something that may, in theory, be useful, but will not be commonly used in the real world

After all, one who wants to "lockdown" a machine with this must own and maintain the whole chain : he must master the bios ""secure boot"" features, for instance. He must compile himself every kernel updates.

If a user can use his own kernel (or any kernel from Debian, redhat or any common distrib), then this user can recompile this kernel without the lockdown code, hence breaking the jail.

I fear that many confusion will rise with such feature.

Kernel lockdown in 4.17?

Posted Apr 4, 2018 7:37 UTC (Wed) by flussence (guest, #85566) [Link] (10 responses)

I think you're correct, this doesn't have good connotations. The threat model for this seems to be to prevent the system administrator from using the system in ways not approved by whoever controls the bootloader. And since the firmware owner can never be the same person who bought and rightfully owns the system — because UEFI/BIOS is still proprietary — this can *only* be used as a form of DRM (the greed kind, not the graphics one).

If this is implemented in mainline it makes Microsoft's end goal significantly easier - “Linux”* (*approved distros) supports Secure Boot now, so would all the clueless UEFI implementers fall in line and kindly remove the unnecessary non-secure mode and user-enrolled keys? For your safety, of course.

Kernel lockdown in 4.17?

Posted Apr 4, 2018 8:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Several years ago I've used DRM lockdown system to ensure the physical security of data, even if the server with them was stolen.

I used a simple "remote attestation" model where the trusted code retrieved remote keys and used them to decrypt the root partition, load its kernel and kexec into it.

Kernel lockdown in 4.17?

Posted Apr 4, 2018 17:06 UTC (Wed) by nilsmeyer (guest, #122604) [Link] (3 responses)

That's a pretty interesting idea, I was toying with a similar idea, using initramfs and a TTL based LUKS key to unlock my device after reboot. My idea was to do this:

Create a random key, store in separate luks key slot
Store random key in etcd (or similar) with TTL (5 minutes or so)
At boot, request password from etcd to auto-unlock
if the key is timed out, prompt for password

I only need a way to authenticate the initrd image. This is mainly so I don't have to manually unlock upon reboot while still maintaining some security, the timeout should be the time it takes to boot, so that when someone physically removes the server the key is no longer valid. Currently, I'm using dropbear in initramfs to login and unlock, but this doesn't verify the integrity of the initramfs either and the private key for dropbear has to be stored in initramfs.

Kernel lockdown in 4.17?

Posted Apr 4, 2018 17:54 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (2 responses)

Before reimplementing the wheel, please see Clevis/Tang solution used in Fedora; for example https://www.usenix.org/conference/lisa16/conference-progr...

Kernel lockdown in 4.17?

Posted Apr 4, 2018 19:01 UTC (Wed) by nilsmeyer (guest, #122604) [Link] (1 responses)

Thanks, that looks very interesting. Dracut isn't very well supported in Debian based distros but that part I can build myself if need be.

Kernel lockdown in 4.17?

Posted Apr 5, 2018 7:02 UTC (Thu) by pabs (subscriber, #43278) [Link]

dracut is available in Debian and is supposed to work, please report bugs if you find any issues. ISTR there was even some talk of switching to it by default a while back.

Kernel lockdown in 4.17?

Posted Apr 5, 2018 15:44 UTC (Thu) by zlynx (guest, #2285) [Link] (4 responses)

A couple of laptops ago, this was a Dell XPS 13, I had it set up to secure boot with an enrolled key of my very own. And I made a script wrapper for the kernel compile to sign everything. If there was some official Fedora way to do it, I didn't find it. I guess they have a separate signature action somewhere in their build process.

But anyway, my method worked and booted a kernel signed by my key. Even though this wasn't great since the signing key was in my /root directory where anyone could find it.

So nothing in secure boot stops the system administrator from using secure boot for their own purposes.

Kernel lockdown in 4.17?

Posted Apr 8, 2018 4:14 UTC (Sun) by flussence (guest, #85566) [Link] (3 responses)

It does help if the hardware manufacturer has the presence of mind to implement UEFI properly… the one system I own with it (some no-name board with an AMI firmware) doesn't even let me turn Secure Boot *on*, there's no hint of it anywhere in the setup (or efivarfs). I'm pretty sure that violates spec.

Kernel lockdown in 4.17?

Posted Apr 8, 2018 18:21 UTC (Sun) by jem (subscriber, #24231) [Link] (2 responses)

Secure Boot wasn't introduced until the 2.3.1 "Errata C" version of the UEFI spec. So if the manufacturer doesn't claim the firmware is newer than that, then it doesn't violate the spec.

Kernel lockdown in 4.17?

Posted Apr 8, 2018 18:58 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

Umm … seriously? they really introduced a major feature in a micro release?

Owch.

Kernel lockdown in 4.17?

Posted Apr 12, 2018 16:11 UTC (Thu) by flussence (guest, #85566) [Link]

It only violates common sense and good taste then… but that's nothing new for firmware.