-1, let's discuss at the next meeting.

I’m not convinced that providing a blanket approval to auto-sign all akmods is an acceptable solution. I think what I’d rather see is a UX where installing the nVidia drivers (or others in the future) forces the disablement of secure boot and requires the user’s conscious (and not easily clicked-through) decision to do this.

If the akmod isn’t signed by a trusted authority, it can be changed at any later time to compromise the system. Thus, auto-signing any akmod that the user might be convinced to install is functionally equivalent to disabling secure boot. I think we should stop pretending otherwise.

I’d rather see is a UX where installing the nVidia drivers (or others in the future) forces the disablement of secure boot and requires the user’s conscious (and not easily clicked-through) decision to do this.

This is not practical as it becomes harder to disable Secure Boot. It has not been mandatory to provide the option to do this since 2015, and I've seen some classes of computers come without the ability to turn off secure boot since 2020.

Well, auto-signing is functionally equivalent to disabling secure boot, so maybe we could just provide the UX that says it's doing so (and maybe make mokutil --sb-state report it as disabled or incomplete)?

Well, auto-signing is functionally equivalent to disabling secure boot, so maybe we could just provide the UX that says it's doing so (and maybe make mokutil --sb-state report it as disabled or incomplete)?

No way. If someone generates a MOK that's automatically used by tools, that's still just as valid of a state as anything else. And both openSUSE and Ubuntu do this today.

If the akmod isn’t signed by a trusted authority, it can be changed at any later time to compromise the system.

I believe it is suitable to say that the admin of the system is a trusted authority. The admin should be able to sign modules, but only the admin. What I'm trying to say is that this should require root privileges (or whatever term is technically correct), which any installation or updating process already does.

I'd like to state that we're currently in the process of adding info about security implications of enrolling MOK and how to remove it to the documentation that is linked from GNOME Software, so that the user can do an educated decision.

I also second Neal's concern about the proposed "let them disable Secure Boot instead" solution since it's really becoming not so uncommon not to have the option to disable SB.

If the akmod isn’t signed by a trusted authority, it can be changed at any later time to compromise the system.

I believe it is suitable to say that the admin of the system is a trusted authority. The admin should be able to sign modules, but only the admin. What I'm trying to say is that this should require root privileges (or whatever term is technically correct), which any installation or updating process already does.

I don't disagree with this statement, except it's not what this change does. The admin is making a choice once for all future akmods. If any rogue package on the system starts shipping a malicious akmod in an update, this will automatically sign and load it. That defeats the intent of Secure Boot pretty much entirely, since its purpose is to ensure that malicious code doesn't enter the critical boot path.

Now, if the admin was prompted as part of the update process to validate any new akmod (including updates of previously-approved ones), that would be maintaining the intent of Secure boot. This would also be a huge inconvenience and likely training users to click through and ignore the risks, but that's a separate UX problem.

My point is that a trusted authority is one that offers you a guarantee that they have actually reviewed and approved the akmods and are asserting they're safe. An admin that auto-signs everything that comes their way is not performing that attestation and is therefore not a trusted authority.

An admin that auto-signs everything that comes their way is not performing that attestation and is therefore not a trusted authority.

There's an inherent trust in the repositories to not provide malware. Repositories are already a trusted authority, by a different mechanism (albeit without warranty). When an admin additionally signs an akmod package that comes from the repository, the signing is nothing but a technicality — translating one mechanism into another.

As a general protection from unwanted packages in the extremely sensitive boot chain, I do agree it is best to have the admin explicitly allow each akmod package, than having them installed silently as dependencies and such.

But then, as the trust in the package is put on its repository either way, they shouldn't have to approve each subsequent update to the package, unless they want to.

An admin that auto-signs everything that comes their way is not performing that attestation and is therefore not a trusted authority.

There's an inherent trust in the repositories to not provide malware. Repositories are already a trusted authority, by a different mechanism (albeit without warranty). When an admin additionally signs an akmod package that comes from the repository, the signing is nothing but a technicality — translating one mechanism into another.

As a general protection from unwanted packages in the extremely sensitive boot chain, I do agree it is best to have the admin explicitly allow each akmod package, than having them installed silently as dependencies and such.

But then, as the trust in the package is put on its repository either way, they shouldn't have to approve each subsequent update to the package, unless they want to.

Again, the problem isn't necessarily the signing of the nVidia akmod; it's that signing the nVidia akmod ALSO means auto-signing any other akmod that appears on the system. I might trust nVidia, but not necessarily any akmod that comes from a third-party repo (such as rpmfusion) or COPR I might have enabled.

I'll be honest, this argument remains specious to me, since the content is coming down from signed repositories that the user already had to approve and trust to install packages.

Also, at this point, I don't consider Secure Boot a security feature anymore. Given all the changes around it in the past few years and the lack of movement on improving in-Linux handling of kmod signatures, I now view it exclusively as an interoperability and system compatibility feature.

This has gone around in circles for years, and unless someone decides to change the Linux kernel such that there's a kernel-level keyring and trust system for kernel module certificates rather than requiring that it be loaded into firmware, there is no room to change the design.

This was discussed in today's meeting, but we did not reach a conclusion. Discussions elsewhere are headed toward possible compromises, and we can revisit this in a future meeting.

The GNOME Software folks have added language to the setup step to make the security implications more clear. With this in place, I'm a weak +1 for this Change. I don't love the security impact, but we're doing our best to at least hand them a foot-gun with a warning label.

This was discussed in the meeting, approved (+6, 0, -2) and announced in the minutes:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/72M3MGF6YXXRPFT6ZEUQ5LSSQG6QQKD2/