[Feature request] Sign kernel for EFI

[bkw777]

[Feature request] Sign kernel for EFI

I don't think there is anything I can do about that. If you want signed kernels, then you don't want mainline kernels. Only Ubuntu can sign anything with their certificates, and they are not signing the mainline builds. Simple as that.

Also, this app only installs/removes deb packages, it doesn't actually copy the kernels or modules directly. That is dpkg's job. The kernels inside the deb packages are either signed or not, and if they're not, I don't know of any way to insert extra commands into the middle of a dpkg install operation to sign with a local self-signed cert on the fly. As far as I can tell, the only way to sign these before installing, would be to extract the deb without installing, sign the kernel with a cert that you had previously generated and enrolled in your bios, repackage into a new deb, and then tell dpkg to install that new deb.

The only realistic way to install signed kernels is if you find some other ppa that suppplies deb packages with signed kernels inside, it would be possible to have the app use that other ppa instead of the regular mainline ppa.

So, the app only ever claimed to do one thing, install the mainline ppa packages. If they are not signed and you want signed, then you don't want them. Or you want to petition the mainline ppa maintainers to sign their packages.

Maybe the proper answer comes via dkms?
https://blog.ubuntu.com/2017/08/11/how-to-sign-things-for-secure-boot

"update-secureboot-policy should soon let you generate and enroll a key; and DKMS will be able to sign things by itself using that key."

https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS

[hoshsadiq]

Yep, sorry if I didn't make it clear but that's what I mean. It would either reuse a key you've enrolled, or generate one for you (and setup enrolling it) and sign it with that.

Do you know of a way to tell dpkg to sign a kernel on the fly while it's installing a deb that has an unsigned kernel inside? I do not.

Probably the answer is going to somehow use dkms, which does things on the fly during kernel installs/removes.

[hoshsadiq]

Do you know of a way to tell dpkg to sign a kernel on the fly while it's installing a deb that has an unsigned kernel inside? I do not.

Nor do I, but then I don't know that much about signing kernels or secure boot.

I think an easier option would be to simply sign it once the kernel is installed.

Seems like things are just in-between right now. mainline ppa will not be signing kernels period, and ubuntu are changing grub to be more strict than it used to be, and all questions/needs/situations are simply not answered and handled yet.
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1788727

I think it's not possible to install and then sign after. That requires dpkg to do an install that it thinks should not be done. Dpkg does not know "oh it's ok, I'm going to make this kernel ok after you install it." dpkg only knows "This kernel is no good, because it is unsigned and you have secure boot enabled."

[hoshsadiq]

I'd have hoped that the error is generated based on what's currently in the /boot, hence why I figured it might be possible to sign the kernel after the deb package is installed and I'd hoped dpkg would pick that. Perhaps my assumptions were way far off.

You say you get this error whenever you interact with apt. That suggests to me that dpkg generates the error as part of installing the package. Or perhaps every time apt runs at all, as long as these packages are installed, including while installing the package. Probably it's really grub generating the error, which dpkg is just running along the way as part of it's post-install stage.

You can't very well avoid dpkg generating the error while it's installing a file, by modifying the file after dpkg has finished installing it.

In fact, a whole other problem is, you can't modify a deb-supplied file anyway. You'd have to generte a new, signed, copy of the deb-supplied file. And then, the bootloader would not know about it, because dpkg ran update-grub (assuming dpkg decided that your bootloader is grub) while it was installing the deb, and at that time, the signed copy didn't exist, and so it's not part of the generated grub menus. And you can't just say "well, run update-grub again", because grub is just the default and most common case, not a guarantee. There are many bootloaders and with efi you don't even need any bootloader. dpkg is already handling all that in some safe way that doesn't brick people's machines, or if it ever does, it's their problem not ours.

This is why I suggested, and apparently not just me, that the answer probably lies in dkms, whose job is to perform exactly that sort of local, host-specific, on the fly operation, while still in the middle of a kernel deb pkg install operation. Though it's usually used to (re)compile an existing 3rd party module against whatever new kernel was just installed. Point being, it's a mechanism to do something host-specific on the fly, while still in the middle of a deb install process, that normally would have required building a host-specific deb so that your host-specific file could be included in it (which would be completely impractical of course). I think dkms does sign modules on the fly now actually. Not a huge leap there, since it's actually compiling the module on the spot. Signing is just one more step of building.

As far as I can tell this is outside the scope of this util. All it does is install and remove deb packages from the mainline ppa. It sounds like what you want is deb packages with different contents than what the mainline ppa supplies, whether you think that's what you want or not. I don't think the idea of signing the kernels after install is valid. It might be possible to do, but it opens up a world of complications that would be backwards to open up.

Consider, the error is really coming from running "dpkg -i foo.deb". It doesn't matter if you ran that command manually, or had this gui front end run it (because that's all this does). You get that error no matter how dpkg got invoked.

The proper fix needs to work regardless how "dpkg -i foo.deb" is run. The process of dpkg installing the deb should account for this new potential requirement, because that's what it is, it's a part of installing the file.

Right now, roughly this happens:
1 .deb includes a file in it
2 dpkg copies file to fs
3 dpkg sets some perms on installed file
4 dpkg does something to determine what if any kind of bootloader you have
5 dpkg does something to get that bootloader to see the new file.
IF dpkg decided that you have grub, then dpkg probaby runs update-grub.
6 update-grub scans for kernels and generates new grub files
7 dpkg decides everything went ok, finalizes the pkg db update, exits.

Signing a kernel almost certianly requires generating a new signed copy of the kernel, not modifying the actual file the .deb supplied. And so, that step has to happen before step 5 above. (And before that also comes deciding somehow if this is even appropriate for the current system.)

Anything else is massive mission creep and just wrong.
To do it after step 7, means we have to re-invent whatever update-grub is doing to decide if you even need signed kernels, re-invent whatever dpkg is doing to decide if you even have grub .97 or grub2 or elilo or no bootloader at all or ntloader or boot0 (freebsd) or any of a hundred other possibilities, then re-invent whatever dpkg does after it decides what bootloader you have (maybe it just runs update-grub, maybe it does more, maybe next week it does something different and we'd need to watch it and change too, forever...) It's crazy.

The proper place to address this new problem is somewhere where it happens simply as part of running "dpkg -i foo.deb", regardless how that happened, manually or from a front-end. That might mean it happens in grub, as part of update-grub, or it might be something dpkg itself does before calling update-grub, or it might possibly done by getting dms to do it, like you create a fake module that dkms thinks it has to update, but instead of compiling some module source against the kernel being installed, it's just a script that generates a signed copy of the kernel being installed, and as long as that just happens to happen before the update-bootloader stage, then the new signed kernel gets picked up by the update-bootloader stage naturally without actually having to add a bunch of new special case handling code to a bunch of other places.

To do it here, meaning, as some other steps after doing dpkg -i, we could only ever do a crap incomplete job that only handles the common case where the user is in fact using grub2, and running "update-grub" actually works. Even then, there is still the problem that it's really too dangerous to touch grub at all. Right now there is just about no risk of breaking someone's system from booting. If it does break, it was dpkg's fault not ours. That's non-trivial.

Probably dpkg, or at least , the deb pkgs themselves, would need to have signing awareness added to them, and that fake module dkms idea isn't really good enough, because even if it works to cause a signed copy of a kernel to be generated, it would not be removed during dpkg -r. dpkg needs to know to do that, either by new code to handle that in dpkg itself, or by adding code for that in the .deb packages pre-un or post-un stages. And again, has to happen before the update-bootloader stage, which again, might not be update-grub, and so we can't reliably solve by just running update-grub ourselves.

[hoshsadiq]

Hello, sorry, I completely forgot about this. I'll be honest, a lot of what you said goes way above over my head. Anyway, there are tutorials on how to sign kernels using self signed certificates, and while I tried to follow them (and broke my computer several times in the process), I've given up now. Thanks for looking into all of this anyway!