Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
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
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 --]

                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publically 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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git