From: Matthias Gerstner <mgerstner@suse.de>
To: linux-integrity@vger.kernel.org
Subject: Ramifications of INTEGRITY_PLATFORM_KEYRING
Date: Wed, 4 Dec 2019 14:57:15 +0100 [thread overview]
Message-ID: <20191204135715.GB11974@f195.suse.de> (raw)
[-- 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 --]
next reply other threads:[~2019-12-04 13:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 13:57 Matthias Gerstner [this message]
2019-12-11 2:56 ` Ramifications of INTEGRITY_PLATFORM_KEYRING Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191204135715.GB11974@f195.suse.de \
--to=mgerstner@suse.de \
--cc=linux-integrity@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).