Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
dkms in bullseye has a sign script that expect the mok key to be in
/root (not /var/lib/dkms/:
dkms: /etc/dkms/sign_helper.sh
/lib/modules/"$1"/build/scripts/sign-file sha512 /root/mok.priv /root/mok.der
"$2"
dkms in bookworm has no sign_tool script anymore but from
https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.8-3/dkms.in via
do_build then preapre_signing it sets sign_file:
debian* )
sign_file="/usr/lib/linux-kbuild-${kernelver%.*}/scripts/sign-file"
and a MOK location (and also generate this MOK if mok_singing_key is
not defined in /etc/dkms/framework.conf):
if [[ -z "${mok_signing_key}" ]]; then
# No custom key specified, use the default key created by
update-secureboot-policy for Ubuntu
# Debian's update-secureboot-policy has no --new-key option
case "$running_distribution" in
ubuntu* )
mok_signing_key="/var/lib/shim-signed/mok/MOK.priv"
mok_certificate="/var/lib/shim-signed/mok/MOK.der"
(...)
if [ ! "${mok_signing_key}" ]; then
mok_signing_key="/var/lib/dkms/mok.key"
fi
echo "Signing key: $mok_signing_key"
if [ ! "${mok_certificate}" ]; then
mok_certificate="/var/lib/dkms/mok.pub"
fi
echo "Public certificate (MOK): $mok_certificate"
# scripts/sign-file.c in kernel source also supports using
"pkcs11:..." as private key
if [[ "$mok_signing_key" != "pkcs11:"* ]] && ( [ ! -f
"$mok_signing_key" ] || [ ! -f "$mok_certificate" ] ); then
echo "Certificate or key are missing, generating self signed
certificate for MOK..."
openssl req -new -x509 -nodes -days 36500 -subj "/CN=DKMS
module signing key" \
-newkey rsa:2048 -keyout "$mok_signing_key" \
-outform DER -out "$mok_certificate" > /dev/null 2>&1
fi
https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.8-3/dkms_framework.conf
# Location of the key and certificate files used for Secure boot.
# mok_signing_key can also be a "pkcs11:..." string for PKCS#11 engine,
as
# long as the sign_file program supports it.
# (default: /var/lib/dkms):
# mok_signing_key=/var/lib/dkms/mok.key
# mok_certificate=/var/lib/dkms/mok.pub
Thus for Debian the the MOK key is generated by dkms on first dkms
build, in /var/lib/dkms, or points the mok_signing_key and
mok_signing_certificate defined by the user in /etc/dkms/framework.conf
So I conclude that the dkms part is nearly done. Only it does not work
(at least on my box due to dkms looking for the sign-file kernel scipt
at the wrong location) but the most critical issue is that the way it
is done it is likely to break interactivity (it will ask on standard
input for the key password while running dkms build, but what if dkms
build is called while installing a module dkms package, or in a
graphical package manager).
At least the way it is done in ubuntu we have debhelper steps in shim-
signed to ask for the password (and they are already there in debian
too).
I believe dkms is not the best suited to manage the MOK generation.
shim-signed is a better fit.
Dkms modules signing is another issue. Handling it in dkms at module
build step is fine and should be kept. But when a new MOK key is
generated or replaced by a new one the dkms modules should be signed
anew with this new key. And dkms does not look like the best place to
handle that use case.
Cheers,
Alban
NB: The dkms prepare_signing step here fails per:
+ prepare_signing
+ '[' '!' '' ']'
+ case "$running_distribution" in
+ sign_file=/usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file
+ echo 'Sign command: /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-
file'
+ [[ ! -f /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file ]]
+ echo 'Binary /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file
not found, modules won'\''t be signed'
+ return
ie the kernel path is wrong. The script is available in:
/usr/lib/linux-kbuild-6.0/scripts/sign-file.
So the MOK is not generated and the dkms modules are not signed.
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Thu, 18 Nov 2021 13:32:58 +0100 Thomas Goirand wrote: > On 11/18/21 7:15 AM, Tomas Pospisek wrote: > > On Thu, 18 Nov 2021, Thomas Goirand wrote: > > > >> On 11/17/21 11:01 AM, Tomas Pospisek wrote: (...) > >> Hopefully, we can have the automation to sign DKMS modules in a non-leaf > >> package. I would strongly suggest we get a package with a very explicit > >> name in it, like "dkms-automatic-mok-signing" so it would do the work. I > >> would absolutely *not* go the path of disabling secure boot when a DKMS > >> module gets installed... > > > > Since I have not looked further I am *guessing* that Ubuntu does the > > automatic creation of the MOK key in the shim-signed package. So I think > > it should be possible to lift Ubuntu's work out of there and also put it > > into the shim-signed package, into postinst or so. > > > > *t > > As I understand, doing updates of shim-signed requires a signature from > Microsoft, so probably it's not the best place to do some change. https://salsa.debian.org/efi-team/shim-signed/-/tree/master/ The efi binaries are signed but not the package itself. Modifying the package postinst and its update-secureboot-policy script are fine. > > As for module automatic signatures, maybe this could go into the dkms > package itself, with some kind of configuration? Again, just a > suggestion... :) > https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/openssl.cnf https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/update-secureboot-policy This ubuntu update-secureboot-policy has a --new-key flag to generate the MOK in /var/lib/shim-signed/mok/. https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/debian/shim-signed.postinst calls update-secureboot-policy --new-key on configure. It also sign the dkms modules. Cheers, Alban
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On 11/18/21 7:15 AM, Tomas Pospisek wrote: > On Thu, 18 Nov 2021, Thomas Goirand wrote: > >> On 11/17/21 11:01 AM, Tomas Pospisek wrote: >>> Our instructions on Secure Boot [1] are a bit scatterbrained and do not >>> specify precisely where the key should exist at. >> >> I was the one who wrote them, after *A LOT* of research about it on the >> internet. It was hard to find, really. >> >> I just explained how to sign, with no intention to have this automated >> (at the time), so no wonder there's no standard path... > > I did not intend my characterisation of the instructions as a critique > of your work. No worries, I didn't take it this way! :) >> Hopefully, we can have the automation to sign DKMS modules in a non-leaf >> package. I would strongly suggest we get a package with a very explicit >> name in it, like "dkms-automatic-mok-signing" so it would do the work. I >> would absolutely *not* go the path of disabling secure boot when a DKMS >> module gets installed... > > Since I have not looked further I am *guessing* that Ubuntu does the > automatic creation of the MOK key in the shim-signed package. So I think > it should be possible to lift Ubuntu's work out of there and also put it > into the shim-signed package, into postinst or so. > > *t As I understand, doing updates of shim-signed requires a signature from Microsoft, so probably it's not the best place to do some change. As for module automatic signatures, maybe this could go into the dkms package itself, with some kind of configuration? Again, just a suggestion... :) Cheers, Thomas Goirand (zigo)
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Thu, 18 Nov 2021, Thomas Goirand wrote: On 11/17/21 11:01 AM, Tomas Pospisek wrote: Our instructions on Secure Boot [1] are a bit scatterbrained and do not specify precisely where the key should exist at. I was the one who wrote them, after *A LOT* of research about it on the internet. It was hard to find, really. I just explained how to sign, with no intention to have this automated (at the time), so no wonder there's no standard path... I did not intend my characterisation of the instructions as a critique of your work. I am extremely happy that you actually *did* the work for all of us so we can stand on the shoulders of what you did. Very much +1 and many thanks really!!! (And thanks & cheers to the Debian EFI Team as well :-D ) I would edit those instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. Please go ahead, and explain that this is the Ubuntu path. Done. I think it'd be preferable if Debian created (or however Ubuntu does it) it's key automatically at that same place as Ubuntu has them, which would make most of the instructions in the wiki [1] unnecessary and would make the user experience much easier and smoother since the (upstream) virtualbox package could install and sign it's modules by itself without any user interaction, just like it happens under Ubuntu (?). ? Well, to begin with, I wonder why the upstream virtualbox package is pushing its compiled modules at the wrong location, but yeah, sure! I guess one can always talk to upstream... Hopefully, we can have the automation to sign DKMS modules in a non-leaf package. I would strongly suggest we get a package with a very explicit name in it, like "dkms-automatic-mok-signing" so it would do the work. I would absolutely *not* go the path of disabling secure boot when a DKMS module gets installed... Since I have not looked further I am *guessing* that Ubuntu does the automatic creation of the MOK key in the shim-signed package. So I think it should be possible to lift Ubuntu's work out of there and also put it into the shim-signed package, into postinst or so. *t
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On 11/17/21 11:01 AM, Tomas Pospisek wrote: > Our instructions on Secure Boot [1] are a bit scatterbrained and do not > specify precisely where the key should exist at. I was the one who wrote them, after *A LOT* of research about it on the internet. It was hard to find, really. I just explained how to sign, with no intention to have this automated (at the time), so no wonder there's no standard path... > I would edit those instruction so that they create the key at the same > location Ubuntu has its MOK keys. However I would prefer not to collide > with some tools or automation or scripts that do the same at the same > place. Please go ahead, and explain that this is the Ubuntu path. > I think it'd be preferable if Debian created (or however Ubuntu does it) > it's key automatically at that same place as Ubuntu has them, which > would make most of the instructions in the wiki [1] unnecessary and > would make the user experience much easier and smoother since the > (upstream) virtualbox package could install and sign it's modules by > itself without any user interaction, just like it happens under Ubuntu (?). > > ? Well, to begin with, I wonder why the upstream virtualbox package is pushing its compiled modules at the wrong location, but yeah, sure! Hopefully, we can have the automation to sign DKMS modules in a non-leaf package. I would strongly suggest we get a package with a very explicit name in it, like "dkms-automatic-mok-signing" so it would do the work. I would absolutely *not* go the path of disabling secure boot when a DKMS module gets installed... That's only suggestion, and I'm not volunteering, so that's only my 2 cents of comments... :) Cheers, Thomas Goirand (zigo)
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On Wed, 17 Nov 2021, Tomas Pospisek wrote: I would edit those [wiki] instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. [...] [1] https://wiki.debian.org/SecureBoot I just updated the instructions accordingly with a pointer to this bug report in case Debian would generate the MOK key automatically in the future. *t
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
(Thomas I hope you don't mind I put you in the Cc) Leif Lindholm wrote: Currently, if dkms is installed, shim-signed prompts to disable kernel/module verification on next boot on some trigger events - to ensure the system will successfully boot (something, not necessarily untampered with) after a kernel upgrade. According to Vorlon, in Ubuntu: "that's since been superseded by code to instead generate and enroll a MOK key and sign all dkms modules with it." This sounds like a very useful feature that would be worth bringing into Debian. I'd like to expand on this. When I install upstream (Oracle's) virtualbox-6.1 then the package tries to compile and sign the required virtualbox modules and fails due to not being able to sign them. As far as I understand the code, the upstream virtualbox-6.1 package expects the MOK keys to be at: # grep "^DEB_.*KEY=" /usr/lib/virtualbox/vboxdrv.sh DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv On a Ubuntu box (I checked on a focal) the keys are there: -rw--- 1 root root 1704 Jul 13 2018 /var/lib/shim-signed/mok/MOK.priv I do not know how they happen to appear there. I tried to find out, but failed due to not having direct access to that focal box. Our instructions on Secure Boot [1] are a bit scatterbrained and do not specify precisely where the key should exist at. I would edit those instruction so that they create the key at the same location Ubuntu has its MOK keys. However I would prefer not to collide with some tools or automation or scripts that do the same at the same place. I think it'd be preferable if Debian created (or however Ubuntu does it) it's key automatically at that same place as Ubuntu has them, which would make most of the instructions in the wiki [1] unnecessary and would make the user experience much easier and smoother since the (upstream) virtualbox package could install and sign it's modules by itself without any user interaction, just like it happens under Ubuntu (?). ? *t [1] https://wiki.debian.org/SecureBoot
