Distro Signature signing

[Clarity]

@fatdog figured this out years ago, it appears.

This PUP forum thread (KLV) is struggling to leap that hurdle. If anyone has insights that would help them, please share.

[rockedge]

@Clarity I followed along as FATDOG was beginning to use it's own kernels as signed.

I kind of been skipping it for awhile but it's a matter now as Microsoft and Apple put more and more screws in.

And if we want to run with the pack and not stay behind peeing with the puppies, this will need to be addressed one way or another.

The big problem lays with the fact that any kernel module compiled let's say to build a VBoxdrv driver for virtualbox, will need to be signed on the fly as it's being compiled or it will not load at all.

So even if there is a signed kernel it will make it difficult to make ones' own kernel modules, like all those WiFi drivers. Because the security chain will go the length and no un-signed modules will work.
How many of us can build and sign the modules easily?

Also will there be difficulty in moving OS's around with self signed keys?

[fredx181]

Not sure what "signed" actually means.
On FatDog I ran modinfo ip_tables just to see:

Code: Select all

# modinfo ip_tables
filename:       /lib/modules/5.4.152/kernel/net/ipv4/netfilter/ip_tables.ko
alias:          ipt_icmp
description:    IPv4 packet filter
author:         Netfilter Core Team <coreteam@netfilter.org>
license:        GPL
depends:        
retpoline:      Y
intree:         Y
name:           ip_tables
vermagic:       5.4.152 SMP preempt mod_unload modversions 

No sign of "signed" in this ip_tables module.
On DebianDog Bookworm I ran the same (Debian has choice for installing "unsigned" or "signed" kernel, this has "signed" kernel):

Code: Select all

root@live:~# modinfo ip_tables
filename:       /lib/modules/5.10.0-9-amd64/kernel/net/ipv4/netfilter/ip_tables.ko
alias:          ipt_icmp
description:    IPv4 packet filter
author:         Netfilter Core Team <coreteam@netfilter.org>
license:        GPL
depends:        x_tables
retpoline:      Y
intree:         Y
name:           ip_tables
vermagic:       5.10.0-9-amd64 SMP mod_unload modversions 
sig_id:         PKCS#7
signer:         Debian Secure Boot CA
sig_key:        4B:6E:F5:AB:CA:66:98:25:17:8E:05:2C:84:66:7C:CB:C0:53:1F:8C
sig_hashalgo:   sha256
signature:      B1:A5:5C:43:44:A9:49:C0:6E:98:E7:01:A7:DC:9B:97:2C:86:FD:43:
		AE:82:70:B6:44:8A:FB:9D:3E:53:60:B2:73:B7:57:ED:48:79:ED:17:
		EB:2B:1A:8B:EE:91:F7:A4:1E:17:80:75:7C:EE:7F:BF:61:FD:67:1C:
		1C:D2:A5:F9:2B:C5:B0:E5:BD:71:3C:E4:4D:76:72:12:86:A6:4E:27:
		C7:25:B8:F3:A1:04:59:A1:EF:E9:78:24:83:CC:AD:2A:B8:94:48:53:
		FB:51:33:93:7B:E1:E7:5E:7D:87:07:5F:CC:D6:06:94:A0:BA:19:CA:
		73:FD:F5:01:09:DC:E2:0D:A6:99:BF:ED:BC:A2:77:70:FD:C9:C3:70:
		21:C2:EB:A7:B9:30:84:A1:E6:E0:D3:C7:83:9B:46:6B:71:22:D2:4E:
		7D:42:88:E2:47:12:5B:52:0B:E1:81:B5:E6:3E:6A:30:A7:66:B1:22:
		99:0C:53:45:3C:0F:20:FE:96:B4:EE:E9:6C:B4:A3:75:54:56:46:FE:
		2C:CB:70:23:0A:FC:16:6A:B1:FF:B7:8F:5D:4C:98:3A:30:F0:F6:B5:
		CB:87:9C:9D:2B:3C:34:26:FE:28:18:22:7C:AD:5E:88:40:62:84:90:
		40:21:29:3D:12:A1:0F:AE:94:9D:72:BD:80:9F:D5:8E

Clearly "signed".
Also I ran: find /lib/modules -name '*.ko' -exec grep -FL '~Module signature appended~' {} \+ which should only give output if one or more modules are NOT signed.
On Fatdog, output was all modules (so all not signed) on Debian there was none (all signed)

[user1111]

Surely only applicable if a user opts to use secure boot, which in itself is a potential security risk (alternative attack vectors). Will all hardware providers opt to only permit secure boot - no, as there's a customer base outside of that.

I boot a layered OpenBSD using a Linux hypervisor (main OBSD system in a SFS, changes stored separately (CoW copy on write)), where changes can be preserved or thrown away (save, or not)). If that hypervisor layer became restricted then I'd switch over to pure OBSD. The predominant benefit of the Linux hypervisor is a broader/deeper range of hardware/devices being supported. If that changed, in effect a massive decline in supported devices/hardware, then it would make sense to drop that for the alternatives.

May mean selected hardware/choices don't work, vendor self-crippling

https://www.itwire.com/business-it-news ... ecure-boot

Or where options exist to have a system still work with that barrier

http://daemonforums.org/showthread.php?p=57379

Personally I've tried UEFI, but more just out of a casual glance, predominately I boot with BIOS. Whilst updating hardware one of my first questions would be whether I can boot legacy mode or not, and if not I'd walk by onto alternatives that could.

I appreciate that for some a secure boot system can be appropriate, servers left unattended where a root kit might be installed via physical contact. As part of my bootup check the hash of the bootloader, MBR etc. that would flag any such changes, which is good enough for me. A greater realistic threat however is that of repo kits, main tree hacked and changed such that those hacks are broadly rolled out across many systems and that circumvent the security in that they signed modules/code.

[rockedge]

Good points @rufwoof , good points.

I don't really need the secure boot and so most of my experience is working with BIOS boot systems. I can't imagine the hardware manufacturer's all will go exclusively UEFI/ secure boot with no legacy BIOS option either, as it is an obvious limiter to making maximum profits

[fredx181]

I don't really need the secure boot ....

Me too, and as long as it's possible to disable it, I guess we don't need a signed kernel.
But I think that more and more that "legacy boot" will NOT be supported in the future, so I guess we should go with the flow for supporting "pure" UEFI boot (with or without secure boot).

[rockedge]

@fredx181 I agree! I know I will be experimenting as I go to make KLV able to Secure boot.

I wonder how Void Linux is going to go with their kernels? I have been sticking to using huge Puppy Linux or custom made kernels in KLV-Airedale and haven't built a WDL or KLV lately with Void kernel.

I just read how to get a real shim from Microsoft using Windows for $99. I wonder now if it would be possible to take some donation money buy such a licensed shim from Microsoft to sign Puppy Linux kernels with.

This is sort of an unpleasant thought though and maybe not a real solution.

1. Go to sysdev.microsoft.com and log in with a Live account.

2. Follow the link to the Verisign (now Symantec) page for creating a new company account. Ignore the use of the word company - you can do this as an individual.

3. Follow the instructions and purchase an individual key for code signing. You'll be emailed a form to attach a copy of your notarised ID to, so get that filled in and signed and send them back a copy by email.

4. Export the key from your browser as a .p12 file.

5. Go back to sysdev.microsoft.com and download the zip file containing winsign.exe. Use pesign or sbsign and the key you exported to sign this file, and then upload it to sysdev.microsoft.com to enable your account.

6. Sign the legal agreements - this just involves you typing your name into a box.

7. Put the file you want to get signed into a cab file. lcab will do this,

8. Sign the cab file with your Verisign key. osslsigncode will do this.

9. Upload the file to sysdev.microsoft.com. The uploader is Silverlight for no obviously good reason.

10. Wait for the upload to be processed. I think this happens a couple of times a week, so be prepared to wait a few days (I had to)

You'll get an email when signing is complete. Download the cab file and use cabextract to retrieve your signed binary.

Total cost is $99 plus however much it costs to get something notarised where you are.

[fredx181]

Mmm... you really want to go for this sort of stuff and pay ?

[Duprate]

Hi! This issue is at the developers level. But I, the user, would like to share my experience...
Initially, I had installed FatDog64 on my PC; for this I created a FAT32 partition, Flag "esp", and placed the EFI boot files there. In the BIOS, I set it to "secure boot", OS Type "Other OS". On the Boot EFI partition I edited the "refind". I installed FatDog64 on another partition. Since then, as I've added other distros, I've only edited the grub.cfg. Everything working fine! I compile my kernel every week!
In the simplicity of my thinking as a "user", I don't see complications. Let's face it: FatDog64, it's made to work!

Note: I forgot to say... If the OS is on the same partition as the EFI, it should be set (the flag) as "esp" and "boot" and that's where the "grub.cfg" should be. If the OS is on another partition, this has to be marked "boot" and that's where "grub.cfg" should be.
I may have been repetitive, but it might be useful to someone...

[Duprate]

FatDog64 EFI boot, edited refind.

[wiak]

I just read how to get a real shim from Microsoft using Windows for $99. I wonder now if it would be possible to take some donation money buy such a licensed shim from Microsoft to sign Puppy Linux kernels with.

This is sort of an unpleasant thought though and maybe not a real solution.

I would not do that. I doubt it is necessary. As far as I understand it, self-signing can be made to work. No need to pay Microsoft anything I feel, which probably wouldn't solve anything anyway.

I don't know, but wouldn't be at all surprised that if you boot with FatDog grub2 then all works fine. My issue is probably that I used an official upstream Ubuntu-based Zorin to do a full install on an ext4 partition I created for it after shrinking down Windows to make space for that on this secure boot enabled machine.

And maybe it is that Ubuntu grub2 that now requires my machine to use signed kernels thereafter since, as that link I posted from askubuntu says:

https://askubuntu.com/questions/1081472 ... -signature

Since the most recent GRUB2 update (2.02+dfsg1-5ubuntu1) in Ubuntu, GRUB2 does not load unsigned kernels anymore, as long as Secure Boot is enabled.

The grub2 used by FatDog might not have this problem. In my case, I have a workaround (using signed Zorin kernel with KLV-Airedale) that works to my satisfaction, so no problem my end.

I do think it will be good not to ignore the matter longterm, but don't buy any junk off Microsoft, but rather it is good we experiment with self signing (virtual machines or whatever we have), on the side only (this is not an urgent matter) and eventually we will have other solutions anyway. Time cures all ills. i.e. not worth worrying about it just now when it effects probably hardly anyone and especially when FatDog style grub2 is working on secure boot enabled machines of some here (I expect that would work for me too, but I can't easily change the arrangement I have so won't bother). FatDog itself does not unfortunately boot on my machine despite having a signed kernel (I'm presuming that's for a different reason - the signed kernel certainly loads - I just hope the setup I have doesn't also need signed modules!... yeah, let's forget it for now is my main feeling - not a critical matter at this time).

[wiak]

Not sure what "signed" actually means.
On FatDog I ran modinfo ip_tables just to see:

Oh no!!
You just gave me something else to try.
I happen to be on my old dev laptop at the moment, running WDL_Arch64. I just ran that modinfo check and the Arch kernel (edit: module ip_tables) I'm using indicates as being signed. That gives me different kernel to try using with KLV-Airedale to see if a non-ubuntu signed kernel will work. Doesn't solve problems related to self-built kernels of course, but important to me to determine once and for all that any signed kernel will be acceptable for my new machine ubuntu-grub2 needs. I presume Arch uses its own signing key. I will report the result of my trying Arch kernel with KLV-Airedale later (not that that will be useful for anyone else...).

Thing is, does this imply the modules all get signed too, and not just the kernel - that makes sense somehow? Does FatDog (which I can't boot) sign its modules too? I was very disappointed FatDog also did not boot for me - my hopes were high and I would have been very impressed. For my machine, the easiest 'solution' is to make sure to always use upstream official kernels, which would be a problem if wanting to use aufs of course (but fortunately I don't). I will try now building WDL-Arch64 on the new machine; if that works/boots I'll will be semi-overjoyed. I assume Void kernel is not itself signed?

[rockedge]

@wiak that's the whole gist of it. signing the kernel means the modules need to be signed as well or they will not load. The process is like a security chain. That is what I mean about building custom modules against the kernel's source. They will need to be signed so the signed kernel will load them.

I think I read that there is also the signed initrd.gz that can be required.

[wiak]

I think I read that there is also the signed initrd.gz that can be required.

That part at least seems to (surprisingly really) be optional. The suggested procedure for including the initrd in the chain seems to be that of including it in a single binary with the vmlinuz and signing the whole lot, but clearly (on my system at least) unsigned WDL initrd works fine as long as kernel is signed, and, as you suggest, the modules also.

[wiak]

Not sure what "signed" actually means.
On FatDog I ran modinfo ip_tables just to see:

Oh no!!
You just gave me something else to try.
I happen to be on my old dev laptop at the moment, running WDL_Arch64. I just ran that modinfo check and the Arch kernel (edit: module ip_tables) I'm using indicates as being signed. That gives me different kernel to try using with KLV-Airedale to see if a non-ubuntu signed kernel will work.

Alas, that turned out to be untrue. I went to the trouble of using build_firstrib_rootfs to build a new WDL_Arch64 on the nvme SSD drive of this annoying laptop and no, it did not boot, claiming wrong signature. But that seemed okay at that point, because I needed to add related Arch Linux .cer key to EFI (I thought), but then I wondered where to find that... No sign of it anywhere (and maybe I needed more any way - I'm just a novice at this). But then I thought I'd double check the Arch kernel was indeed signed. I first again ran the modinfo command for module ip_tables and certainly there seemed to be info about certificates. Then I thought, oh... main command to check the kernel itself with (I think) is 'sbverify --list whatever_kernel', so I tried that... sigh...

It reported 'No signature table present', which I believe means it is not signed afterall... That equates with what I'd earlier read on Arch Wiki:

https://wiki.archlinux.org/title/Unifie ... ion_medium

Note: The official installation image does not support Secure Boot (FS#53864). To successfully boot the installation medium you will need to disable Secure Boot.

Arch has this listed as a bug which is becoming severe and needs addressed:
https://bugs.archlinux.org/task/53864

This issue is getting more and more severe with time, since (putting aside 99% of computers are sold with SB enabled by default), W10 certification requirements dropped the "can be disabled" criteria and most OEMs are getting quite lazy.rch has that posted as a bug that is becoming quite severe in its effect: https://bugs.archlinux.org/task/53864

Confusingly, Arch does seem to sign modules, though how that works without their signing the kernel beats me:
https://wiki.archlinux.org/title/Security#Secure_Boot

Restricting module loading
The default Arch kernel has CONFIG_MODULE_SIG_ALL enabled which signs all kernel modules build as part of the linux package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as virtualbox-host-modules-arch cannot be loaded. Kernel module loading can be restricted by setting the kernel parameter module.sig_enforce=1. More information can be found at the kernel documentation.

Seems to me there is no easy way out of all of this. I'll stick with my signed Zorin kernel/modules set up (including using these with my KLV-Airedale install and so on for now). In fact, now that I've gone to the trouble of building a new WDL_Arch64 on this machine I'll modify it to use the same kernel - why not, I find that easy to do, and it works; actually it seems to be signed by Canonical (not too surprising since Zorin is based on Ubuntu) so I suspect any official Ubuntu kernel/modules combination could be used on this machine now.

[wiak]

So I now have full installed Zorin lite 16 XFCE, WDL_zorin (being weedogit frugal install of same distro), KLV-Airedale64 and WDL_Arch64 on this HP Probook secure-boot machine; all using Zorin's ubuntu signed kernel/modules. I'm fine with that actually, but certainly not easy for the average non-technical user to arrange similar on a similar secure boot enabled dual booting with Windows machine.

Ridiculous amount of RAM available, but it's a business machine - not really mine ... boo hoo

EDIT: I've discovered that Ubuntu has a github page that explains "how to sign Ubuntu kernels using a Machine Owner Key": https://github.com/berglh/ubuntu-sb-kernel-signing
Tons of kernels are available right up to most recent (e.g. currently 5.18.0-rc2).
See:
https://kernel.ubuntu.com/~kernel-ppa/mainline/
https://github.com/bkw777/mainline

This one (linux-image-5.15.0-25-generic) is also already signed it seems: https://launchpad.net/ubuntu/+source/linux-signed

[user1111]

If you UEFI boot a kernel that was signed, perhaps built with localyesconfig so all modules were incorporated into that kernel, that solely existed in order to kexec ... boot another kernel, that wasn't signed (and loaded unsigned modules), that might (??) be enough to pass UEFI security.

https://oldforum.puppylinux.com/viewtop ... 8#p1041568

Compiling kexec
https://oldforum.puppylinux.com/viewtop ... 5#p1040675

[rockedge]

@wiak you've gathered good information getting this machine up and running.

I have been following along and so yesterday I took out of file cabinet in the garage a DELL laptop that has Secure Boot. This machine can be tested rigorously because even if it gets bricked it is more of a win what not to do than the loss of this laptop. It lived a long life as a High School Biology teacher's main driver for more than several years and once had Windows and was domain controlled by the school's IT guy. One day it was replaced by a ChromeBook which is a pretty piece of plastic lingering on the desk taking up space. Anyway I was given the thing because it had begun to "act strange". First thing I did back then was replace the HDD and RAM sticks.

I am right now running KLV-Airedale-beta12 and Puppy Linux Bionic64 on it. It has Legacy Boot and UEFI Boot options. But oddly the Secure Boot option is greyed out and can't be selected at all!

Wondering now if by swapping in the new HDD (500 Gib) if that had an effect on the Secure Boot functions.

So I have been booting all morning, one coffee = 5 boots. In legacy BIOS mode and now in UEFI mode (with the Secure Boot enable still greyed out)

Both OS's are booting in UEFI mode with the HDD partitioned into sda1 (512 MiB) sda2 (400 GiB) swap (1 Gib)

Back when I first put Puppy in it wouldn't boot so I jammed some EFI.img files and other tidbits into sda1 along with Grub4Dos and the operating system frugally installed on sda2.
This boots Puppy Linux in both UEFI or BIOS. Now KLV-Airedale will boot also in either mode BUT KLV in the UEFI mode has some kind of overlayfs error during the boot cycles and starts without something because the default initrc is used that starts KLV up with no windows manager and 3 terminals and a clock (TWM can't be found of course.)

[bigpup]

It has Legacy Boot and UEFI Boot options. But oddly the Secure Boot option is greyed out and can't be selected at all!

Dell probably setup the UEFI firmware to control secure boot enable/disable by how you set UEFI or Legacy modes.
UEFI -> secure boot is enabled. Could also only have secure boot disable/enable option when it is in UEFI mode.
Legacy -> secure boot is disabled. Some firmware automatically does this when legacy mode is selected.

Depending on exactly how old the UEFI firmware is.
Dell may have not set it up to even use secure boot feature.

Manufactures can setup the UEFI firmware to operate any way they want to.
So exactly how the UEFI setup will work is up to the manufacture of the computer.

Most newer UEFI firmware will automatically disable secure boot when legacy or CSM(basically new name for legacy) mode is selected.
Now it is common that a drive not using the GPT partition table will trigger the UEFI firmware to operate in CSM mode.

If secure boot disable/enable option is being controlled by UEFI or legacy mode selection.
Grayed out secure boot selection may not be active until you select UEFI mode, save setting, now boot using that setup, and enter UEFI setup again.

[rockedge]

@bigpup No matter what I set so far, the Secure Boot remains greyed out. I have it in the system setup (F2 during the boot start cycle) right now looking at all of the selections. The machine goes into UEFI mode but secure boot remains greyed out so far no matter what I am selecting.

[bigpup]

Stays grayed out after changing to UEFI mode, save settings in the UEFI setup, boot using this new setup, shutdown and boot into UEFI setup?
If yes, it is still grayed out.

Then secure boot option is not a usable setting or it is automatically set by UEFI or Legacy mode selection.

If this is a very old version of UEFI firmware and Dell decided to do it.
Secure boot option may not be usable in this firmware.

Do you know what version of Windows was originally on the computer when it was new?
UEFI really did not get supported until Windows 8.1

If it originally had Windows 7.
Dell could have had the UEFI firmware setup in legacy mode and coded the secure boot setting to not work.

[bigpup]

when I first put Puppy in it wouldn't boot so I jammed some EFI.img files and other tidbits into sda1 along with Grub4Dos and the operating system frugally installed on sda2.
This boots Puppy Linux in both UEFI or BIOS.

In UEFI mode.
If secure boot is enabled.
Should need to provide a security key the first time you boot with UEFI mode.
Key word should.

Again ,not sure what the age of this UEFI firmware is or how Dell coded it to work.
In the early days of UEFI, it was all over the place, what did what and when.

[Duprate]

Hi! On my PC, in Secure Boot setting, I have to select OS type. Selecting "Other OS" does not require a security key. Selecting "Windows OS" requires a security key.
When it is necessary to change the PC for a newer one, I will have to research a lot about the settings and the motherboard used.

"Little bird that wants to fly, must take good care of its wings!"

[fredx181]

Useful info by rcrsn51 here: viewtopic.php?p=54810#p54810
Valuable for non Debian users too, I guess.

[wiak]

Useful info by rcrsn51 here: viewtopic.php?p=54810#p54810
Valuable for non Debian users too, I guess.

I saw that, but it doesn't mention ubuntu's grub2 requiring signed kernels now. It may be that other grub2 implementations don't have that requirement, but dual-booting Windows with ubuntu (and ubuntu-based distros) is probably a common situation. Just to confirm the problem in practice, I'm going to try transferring my Ubuntu/Zorin grub2 over to the usb stick I have that successfully boots non-signed kernel KLV-Airedale - I expect it to not work with message kernel not signed.

[Clarity]

Hi @rockedge. Can you go the the Dell Support website and disclose what year that Dell was manufactured?

Thanks in advance

[rockedge]

@bigpup This laptop was a Windows 7 machine upgraded to Windows 10. I do think that the machine has the Secure Boot option disabled. When I got it I deleted Windows 10 and reformatted the hard drive to FAT32 sda1(boot flag set) and an EXT4 sda2.

With UEFI enabled KLV-Airedale does not load correctly and I see an overlayfs error about a layer not able to be mounted.

With the laptop in legacy BIOS it boots perfectly error free. I am really just starting to try out different configurations thoroughly

[Phoenix]

@rockedge

Just curious but have you tried using KeyTool and inserting your own set of keys? (Or using the OEM tools to add in keys?) In order to secure boot to be active a key merely needs to be present in the primary key slot. Although please don't simply toss one in and forget about it, otherwise you'll somehow have to disable/clear it the next time you modify. Also you will also want to add in the signature for KeyTool otherwise you can't get in then later!

Source: https://www.rodsbooks.com/efi-bootloade ... eatingkeys and my own experience at making a Surface Pro 2 Secure boot work.