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

[James Bottomley]

On Thu, 2025-06-05 at 15:43 +0200, Vitaly Kuznetsov wrote:
> James Bottomley <James.Bottomley at HansenPartnership.com> writes:
> 
> > On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote:
> > > One additional consideration is the fact that we already trust
> > > 'db' for dm-verity (since 6fce1f40e951) and kexec (since
> > > 278311e417be) and especially the later gives someone who is able
> > > to control 'db' access to CPL0; a 'db'-signed module (IMO)
> > > wouldn't change much.
> > 
> > Well, the kexec case is because kexec has to verify the new kernel
> > as shim would and shim would use the UEFI keys.  The dm-verity one
> > was added for a cloud use case by pressuring the maintainers in
> > spite of the objection to using the platform keyring (it went to
> > dm-devel only so not many integrity people saw it):
> > 
> > https://lore.kernel.org/all/20240617220037.594792-1-luca.boccassi@gmail.com/
> > 
> > The point here is I do think the cloud use case is legitimate, but
> > it can't be supported simply by ignoring the bare metal security
> > domain separation concerns of the integrity community.  The
> > argument that distros have done it so it must be safe isn't really
> > a winning one (especially as there's no clear explanation of why
> > they did it).  So either you need a better argument or we need a
> > way to support both sets of communities ... which is why I was
> > wondering about a runtime differentiator.
> 
> 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? 

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.

> 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).

Regards,

James