Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification

James Bottomley [off-list ref] writes:

On Thu, 2025-06-05 at 15:43 +0200, Vitaly Kuznetsov wrote:

quoted

James Bottomley [off-list ref] writes:

quoted

On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote:

So far, I got two 'runtime' ideas:
- Observe MokListTrustedRT and distrust .platform when it is
non-empty. This can, of course, be combine with a Kconfig for those,
who do not want it at all.

Well, not sure about that specific variable.  It seems to be set but
not used by shim (however it is used in the kernel to decide whether to
import the MoK list), so how would someone with a current distrusted db
get it set?  But there's also MokIgnoreDB (which is actually a RT
import of MokDBState) which is used to prevent importing the db certs
into the platform keyring in the first place.

I think the reason this is so fragmented is because we didn't really
co-ordinate with shim when all the variables and switches were added. 
Perhaps we should document all the variables and expectations before
deciding on a mechanism? 

I was hoping Peter (pjones@) can help us here) Generally, I agree that
as these variables originate in shim, we should describe them there and
not try to give them some potentially undesired meaning in kernel.

The one thing we can guarantee is if the cloud use case is booting
without shim (is it?) then none of the RT variables will get created,
so checking any (or a set) of them would work.

Personally, I always advocate for injecting shim in the boot chain at
least when distro kernels are used: shim provides SBAT revocation
mechanism which is likely going to be used when a new secureboot related
vulnerability is discovered. SBAT was used for UKIs only but a mechanism
for embedding it into the Linux kernel itself is coming (already merged
for 'zboot' arches, pending for x86). If, however, someone is signing
his own kernels and can use 'dbx' or even revoke the cert in case of a
problem, then I guess shim can be avoided.

quoted

and/or
- Sysctl toggle. Keep things as they are by default but make
.platform trusted (either for modules or for everything) when
switched 'on'. This can (optionally) by combined with a previous idea
and have e.g. an 'auto' state for the toggle which follows
MokListTrustedRT.

I'm less keen on user specifiable runtime because the security policy
of the system using a lockdown to make root less privileged than ring 0
can't allow a malicious root to weaken it.  However, let's see if we
can get a proposal that would mitigate that concern.

Ideally, if we can get to something that works for everyone at runtime,
we can remove the current Kconfig explosion which is definitely adding
to the confusion (as shown in the Debian bug reports).

-- 
Vitaly