Message-ID: <88773.1452562139@eng-mail01.juniper.net>
Date:	Mon, 11 Jan 2016 17:28:59 -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 

Hi David,

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

> Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> 
> > Is this the primary use case scenario for your patches?
> > Unfortunately, your posted patches would break the existing IMA
> > trust model.
> 
> Why so?

The intent is that the 'vendor' of a software solution be able to
provide a kernel with one or more .system keys as the root of trust.
(In many cases, this root of trust may be tied to a system that does
measured boot as well.)

Further, that the 'vendor' provide a mechanism where a 'machine owner'
is able to be delegated to add new certificate authorities to a machine
owner keyring and those certificates may be used to sign signing keys
which may in turn be added to the .ima and/or .evm system keyrings to
ensure that IMA signed files are able to be run by the system.

As you suggested in an earlier message thread, it is NOT intended that
generic commercial Certificate Authorities get involved with this set of
operations.

The 'machine owner' key may also be used to add additional third-party
certificate authorities or signing keys to appropriate keyrings in the
system (generally the '.ima_mok' or the .ima keyrings).

> The patches give you per-keyring control over restricting what is
> permitted in a keyring, allows you to use any criteria you like,
> whether it be just the contents of that keyring or CA certs in some
> other keyring(s) and a blacklist.

Could you ellaboriate on the identify of 'you' in this case? Is it the
vendor the system which is trying to warranty the software provided to
the machine owner? Or, is it the 'machine owner'?

> In other words, it should be able to do everything one can do now -
> except that it controls linkage between trusted keyrings with the same
> restrictions as adding new keys.

Hmmm... I suspect I may be missing something.

If the 'vendor' selling the software desires that the 'machine owner'
not extend the kernel with new kernel modules, how is that provided for
in your linkage model?

Another use case, is that the 'vendor' trusts a third-party to properly
deliver both LKMs and user-land programs, but only if the 'machine
owner' explicitly authorizes the keys for that 'third-party' explicitly.

As you may see here, I am attempting to outline a use modle where it is
possible to build up a hierarchy tree of trust rather than a flat set of
keys that are all-powerful.

Delegation to add a key into the .ima keyring is important.

Keeping signing keys separate from delegated certificate authority keys
is also important.

> So if it breaks the IMA trust model, then doesn't that suggest that
> the trust model is broken anyway?

It is possible that I do not properly understand your new per-key
control over a keyring. I would welcome enlightenment.

One of the fundamental assumptions of a big server is that a kernel that
might need to be running non-stop for many years, but might unload and
reload LKMs more often than that and will certainly have the possibility
of updating user-land software (hopefully without needing a reboot) on a
periodic basis.

I hope that my message provides some insight into the problem at hand.

	Thank you,
	-- Mark

Powered by blists - more mailing lists