[PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING

[Michal Suchánek]

On Mon, Sep 11, 2023 at 11:39:38PM -0400, Nayna wrote:
> 
> On 9/7/23 13:32, Michal Suchánek wrote:
> > Adding more CC's from the original patch, looks like get_maintainers is
> > not that great for this file.
> > 
> > On Thu, Sep 07, 2023 at 06:52:19PM +0200, Michal Suchanek wrote:
> > > No other platform needs CA_MACHINE_KEYRING, either.
> > > 
> > > This is policy that should be decided by the administrator, not Kconfig
> > > dependencies.
> 
> We certainly agree that flexibility is important. However, in this case,
> this also implies that we are expecting system admins to be security
> experts. As per our understanding, CA based infrastructure(PKI) is the
> standard to be followed and not the policy decision. And we can only speak
> for Power.
> 
> INTEGRITY_CA_MACHINE_KEYRING ensures that we always have CA signed leaf
> certs.

And that's the problem.

>From a distribution point of view there are two types of leaf certs:

 - leaf certs signed by the distribution CA which need not be imported
   because the distribution CA cert is enrolled one way or another
 - user generated ad-hoc certificates that are not signed in any way,
   and enrolled by the user

The latter are vouched for by the user by enrolling the certificate, and
confirming that they really want to trust this certificate. Enrolling
user certificates is vital for usability or secure boot. Adding extra
step of creating a CA certificate stored on the same system only
complicates things with no added benefit.

> INTEGRITY_CA_MACHINE_KEYRING_MAX ensures that CA is only allowed to do key
> signing and not code signing.
> 
> Having CA signed certs also permits easy revocation of all leaf certs.

Revocation can be also done be removing the certificate from the keyring.

If the user can add it they should also be able to remove it.

> Loading certificates is completely new for Power Systems. We would like to
> make it as clean as possible from the start. We want to enforce CA signed
> leaf certificates(INTEGRITY_CA_MACHINE_KEYRING). As per
> keyUsage(INTEGRITY_CA_MACHINE_KEYRING_MAX), if we want more flexibility,
> probably a boot time override can be considered.

If boot time override can exist it can as well be made permanent with a
Kconfig option.

I think that a boot time override is even more problematic for security
than a Kconfig option - the kernel arguments are rarely signed.

Thanks

Michal

> 
> Thanks & Regards,
> 
>     - Nayna
> 
> 
> > > 
> > > cc: joeyli <jlee at suse.com>
> > > Signed-off-by: Michal Suchanek <msuchanek at suse.de>
> > > ---
> > >   security/integrity/Kconfig | 2 --
> > >   1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
> > > index 232191ee09e3..b6e074ac0227 100644
> > > --- a/security/integrity/Kconfig
> > > +++ b/security/integrity/Kconfig
> > > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING
> > >   	depends on INTEGRITY_ASYMMETRIC_KEYS
> > >   	depends on SYSTEM_BLACKLIST_KEYRING
> > >   	depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS
> > > -	select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS
> > > -	select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS
> > >   	help
> > >   	 If set, provide a keyring to which Machine Owner Keys (MOK) may
> > >   	 be added. This keyring shall contain just MOK keys.  Unlike keys
> > > -- 
> > > 2.41.0
> > >