Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

automate running "sudo mokutil --import /var/lib/dkms/mok.pub" #429

Open
adrelanos opened this issue Jul 11, 2024 · 6 comments
Open

automate running "sudo mokutil --import /var/lib/dkms/mok.pub" #429

adrelanos opened this issue Jul 11, 2024 · 6 comments
Assignees

Comments

@adrelanos
Copy link
Contributor

As of Debian bookworm, the most non-intuitive, difficult for users to figure out setup step that must be applied on Secure Boot enabled systems is the following:

sudo mokutil --import /var/lib/dkms/mok.pub

This is documented in DKMS readme but that is not easily discovered by users.

@scaronni
Copy link
Collaborator

If we automate it, and the user does not know what's happening, it will be prompted with the MOK enrollment screen.

If the user cancels the operation, then the automation will try to rerun it again and again. I'm strongly against this.

What we can do, is to add a hint/message to the output if the MOK key has not been enrolled yet. I'll make a prototype as soon as the other merge request are closed.

@scaronni scaronni self-assigned this Jul 11, 2024
@scaronni
Copy link
Collaborator

scaronni commented Jul 11, 2024

Something like this (fake output):

# dkms build -m nvidia/555.58.02 -k 6.9.7-200.fc40.x86_64
Sign command: /lib/modules/6.9.7-200.fc40.x86_64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

The public certificate is not imported yet, please run the following command to allow using the built modules with SecureBoot:
mokutil --import /var/lib/dkms/mok.pub

Cleaning build area... done.
Building module(s)....................... done.
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-modeset.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-drm.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-uvm.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-peermem.ko
Cleaning build area... done.

@adrelanos
Copy link
Contributor Author

Anything would be an improvement over the current state.

However, it seems that DKMS already automates this action on 1 Linux distribution, namely Ubuntu. Here is the related source code copied here for convenience:

    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 [[ ! -f ${mok_signing_key} || ! -f ${mok_certificate} ]]; then
                    if [[ ! -x "$(command -v update-secureboot-policy)" ]]; then
                        echo "Binary update-secureboot-policy not found, modules won't be signed"
                        return
                    fi
                    # update-secureboot-policy won't create new key if $mok_certificate exists
                    if [[ -f ${mok_certificate} ]]; then
                        rm -f "${mok_certificate}"
                    fi
                    echo "Certificate or key are missing, generating them using update-secureboot-policy..."
                    SHIM_NOTRIGGER=y update-secureboot-policy --new-key &>/dev/null
                    update-secureboot-policy --enroll-key
                fi

                ;;
        esac
    fi

As per the source code comment "Debian's update-secureboot-policy has no --new-key option" found in the source code I pasted above, it seems like DKMS developers decided they do not wish to run sudo mokutil --import but instead would like to proxy it through update-secureboot-policy. (For me, no having Ubuntu installed.) It's hard to find the source code for update-secureboot-policy and it apparently also does not have a man page. So I don't know yet what it does.

It may provide some sort of "moderation" (avoidance of adding keys the user does not wish to add, avoidance of adding keys over and over again) or other usability features.

Debian as DKMS source code says lacks the --new-key option. I plan to inform Debian in form of a bug report / feature request. Other distributions might totally lack the update-secureboot-policy tool.

@adrelanos
Copy link
Contributor Author

adrelanos commented Jul 13, 2024

@evelikov
Copy link
Collaborator

Fwiw personally I'm not excited about having more distro specific paths. The fact that update-secureboot-policy has diverged across distros (is undocumented, projects lacks CI, contribution guildlines etc) makes things even less compelling.

If the latter is resolved, I would be more supportive of the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants