Ramifications of INTEGRITY_PLATFORM_KEYRING

Ramifications of INTEGRITY_PLATFORM_KEYRING

[Matthias Gerstner]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Hi,

at SUSE we implemented an integration test for our enterprise kernels
that checks the functionality of various IMA/EVM related features like
IMA appraisal with digital signatures. To do this a custom CA
certificate is enrolled as a MOK certificate in the system. The
according public key is then loaded into the .ima kernel keyring to be
used for verification of security.ima signatures.

With a recent update we did from kernel version 4.12 to version 5.3 a
regression in this integration test was reported by our QA team. As it
turned out the reason is kernel option INTEGRITY_PLATFORM_KEYRING=y,
which is the default setting our kernel engineers took over. With this
option enabled a couple of platform certificates are no longer loaded
into the .secondary_trusted_keys keyring but into the new .platform
keyring. And IMA only uses those keys to verify things like kexec any
more.

The certificate we enrolled as MOK in the system is now also part for
the .platform keyring, causing us to be unable to load the required
public key into the .ima keyring.

I was able to still get things to work by building my own custom kernel
with the custom CA being built into the kernel which is a lot of more
effort, however, and a scenario we can't easily support for our
customers.

I can understand the reasoning of that new option, that trusting
arbitrary platform certificates shipped with the hardware might not be a
good idea. I wonder, however, whether moving these certificates from
.secondary_trusted_keys to .platform doesn't also affect other
components than just IMA?

I would be interested in your view on this and any advice.

Cheers

Matthias

-- 
Matthias Gerstner <matthias.gerstner@suse.de>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Phone: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Felix Imendörffer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Ramifications of INTEGRITY_PLATFORM_KEYRING

[Mimi Zohar]

Hi Matthias,

On Wed, 2019-12-04 at 14:57 +0100, Matthias Gerstner wrote:
> I was able to still get things to work by building my own custom kernel
> with the custom CA being built into the kernel which is a lot of more
> effort, however, and a scenario we can't easily support for our
> customers.
> 
> I can understand the reasoning of that new option, that trusting
> arbitrary platform certificates shipped with the hardware might not be a
> good idea. I wonder, however, whether moving these certificates from
> .secondary_trusted_keys to .platform doesn't also affect other
> components than just IMA?
> 
> I would be interested in your view on this and any advice.

The pre-boot keys were probably also being used to verify 3rd party
kernel modules.  If the kernel was built with
CONFIG_SYSTEM_EXTRA_CERTIFICATE, the customer could insert their key
post build.[1]  This would obviously require the kernel to be
resigned.

I agree there needs to be a simpler way of including a customer key,
without requiring them to resign the kernel.  Do you have some
thoughts?

Mimi

[1] c4c361059585 ("KEYS: Reserve an extra certificate symbol for
inserting without recompiling")