linux-kernel - Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19583.1452565555@eng-mail01.juniper.net>
Date:	Mon, 11 Jan 2016 18:25:55 -0800
From:	"Mark D. Baushke" <mdb@...iper.net>
To:	David Howells <dhowells@...hat.com>
CC:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>,
	Marcel Holtmann <marcel@...tmann.org>, <petkan@...-labs.com>,
	<linux-security-module@...r.kernel.org>,
	<keyrings@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring 

David Howells <dhowells@...hat.com> writes:

> Signing keys go in .ima only?

Yes, that is the current intent... it is not yet clear to me if it
should also be in play for any .evm keys or not.

> It still doesn't clarify entirely why .ima_mok exists separately from
> .system_keyring from a technical point of view.

IMA is an optional subsystem. Having a keyring for it to use as needed
seems more flexible to me than getting all of the .system_keyring
stakeholders to agree to any new semantics that might be needed.

Rules on how .system_keyring mature and are managed would seem to be
something that has multiple stakeholders.

If a .ima_mok exists, then we can partition the rules associated with
.ima_mok additions and deletions to being a chain of trust that is used
to authorize a given .ima key entry to be permitted to be used and not
fight with other .system_keyring semantics.

For example,

    keyctl clear %:.sysmtem_keyring

locks out adding keys to the primary keystore. That may be exactly the
correct thing to do to stop adding new LKM keys. While still allowing
new keys to be added to the .ima_mok that can in turn only authorize
the addition/deletion of .ima keys.

With regard to a .blacklist keyring type, I have no objections to
sharing a blacklist accross the system.

Sometime soon I need to hunt down the [RFC PATCH 14/15] KEYS:... and
figure out how the restriction functions are supposed to work.

I appreciate the time you have taken to write a response to my message.

I hope that I have managed to provide you have a better understanding of
the goals of a multi-tenant IMA system...

	Thanks,
	-- Mark