[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: