Message-ID: <d34555e2b0c4746fc01d5295959a434befcf8b18.camel@HansenPartnership.com>
Date: Tue, 03 Jun 2025 09:03:22 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>, 
	linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org, 
	linux-modules@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, 
 keyrings@...r.kernel.org, David Howells <dhowells@...hat.com>, David
 Woodhouse <dwmw2@...radead.org>, Jonathan Corbet <corbet@....net>, Luis
 Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>, Sami
 Tolvanen <samitolvanen@...gle.com>, Daniel Gomez <da.gomez@...sung.com>,
 Mimi Zohar <zohar@...ux.ibm.com>, Roberto Sassu <roberto.sassu@...wei.com>,
 Dmitry Kasatkin <dmitry.kasatkin@...il.com>, Eric Snowberg
 <eric.snowberg@...cle.com>, Paul Moore <paul@...l-moore.com>, James Morris
 <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Peter Jones
 <pjones@...hat.com>, Robert Holmes <robeholmes@...il.com>, Jeremy Cline
 <jcline@...hat.com>, Coiby Xu <coxu@...hat.com>, Gerd Hoffmann
 <kraxel@...hat.com>
Subject: Re: [PATCH RFC 1/1] module: Make use of platform keyring for module
 signature verify

On Tue, 2025-06-03 at 10:52 +0200, Vitaly Kuznetsov wrote:
> James Bottomley <James.Bottomley@...senPartnership.com> writes:
[...]
> > Also, are you sure a config option is the right thing?  Presumably
> > Red Hat wants to limit its number of kernels and the design of just
> > linking the machine keyring (i.e. MoK) was for the use case where
> > trust is being pivoted away from db by shim, so users don't want to
> > trust the db keys they don't control.  If the same kernel gets used
> > for both situations (trusted and untrusted db) you might want a
> > runtime means to distinguish them.
> 
> I was not personally involved when RH put the patch downstream (and
> wasn't very successful in getting the background story) but it
> doesn't even have an additional Kconfig, e.g.:
> https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/commit/03d4694fa6511132989bac0da11fa677ea5d29f6
> so apparently there's no desire to limit anything, basically,
> .platform is always trusted on Fedora/RHEL systems (for a long time
> already).

It sounds like that's just distro politics:  RH wants to enable binary
modules (by allowing them to be signed) but doesn't want to be seen to
be signing them (so they can't be signed with the embedded RH key) so
that gamers can have performant graphics drivers and the like.  Thus it
mixes in the db keyring, which usually contains several Microsoft
certificates and also one from the ODM manufacturer, so now it can send
would be shippers of binary modules to those groups to get them signed.
If you only have the built in and MoK keyrings, the only possible
signers are either RH or the machine owner ... who isn't a single
entity to deal with.  Personally I think this is a bit daft: Debian
manages an out of tree module infrastructure using DKMS and MoK
signing, so I can't see why RH can't get it to work in the same way.

> As part of the RFC, I'd like to try to understand under which
> conditions people may not want to trust 'db'. In the most common use
> case, 'db' is used to authorize shim and the kernel is signed by a
> cert from shim's vendor_db, not trusting 'db' for modules after that
> seems somawhat silly. Maybe we can detect the fact that the user took
> control over the system with MOK and untrust .platform only then
> (while trusting it by default)?

Well, I think it's pretty obvious that in a standard secure boot system
most people wouldn't want either Microsoft or the ODM manufacturer
being in a position to sign module code for their systems.  Indeed,
when this was first mooted by Red Hat years ago, I thought Microsoft
refused to be the CA for our modules anyway.  From a security point of
view, it's separation of concerns: the standard secure boot database
guards access to the UEFI boot time before ExitBootServices.  The
kernel is a completely separate security domain and should be guarded
by different keys.

> A runtime toggle is not something I thought much about: the sole
> purpose of this part of 'lockdown' (limitimg unsigned modules load)
> seems to be to prevent someone who already has 'root' on the system
> to gain kernel level access to e.g. hide its activities. In case root
> can decide which keys are trusted, isn't it all in vain?

Not exactly, the purpose of lockdown is to make root less privileged
than ring 0 (the kernel), so that a user space privilege escalation
does less damage.  The gold standard for all of this is supposed to be
to foil an Evil Maid attack (physical access) but I don't think we're
quite there yet.  From the point of view of the keyrings a lot of
others (like .ima) have trusted signing requirements meaning root can't
simply add keys, they have to be signed by keys in the existing trusted
keyring as well.

>  Or maybe if the toggle is to just trust/not trust .platform (and not
> e.g. disable signatures verification completely, inject a new
> key,...) this is acceptable? Another option is to have a kernel
> command line parameter but this is complicated for users.

I was thinking that if the goal is simply to enable cloud db then the
toggle could be detecting the presence of the MoK variables.  However,
if the distro politics thought above is correct, that won't work for
the RH use case of enabling additional binary modules by getting others
to sign them.  Until we have UKI signing of the kernel command line,
it's not such a safe vector to use for switches like this because it
makes the Evil Maid problem worse (and they're hard for users to manage
anyway as you say).

Regards,

James

Powered by blists - more mailing lists