Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Mi, 2016-07-27 at 13:09 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 12:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mi, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
> >> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> >> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> >> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >> > >

> I would like someone to explain why using the keyring mechanism for
> this in the first place is a good idea.
> 
> As far as I can tell, the design goals of "keys trusted by the kernel
> for modules, firmware, etc" are:
> 
>  - Keys are added at build time or, according to potentially
> system-specific rules, at boot time.

Currently, only the builtin keys are loaded onto the .builtin_trusted
keys. The keyring is locked so that no other keys can be added.  Trust
in these keys is based on the secure boot signature chain of trust
verification of the kernel image.

>  - Keys should specify what they're trusted *for*.  Some keys should
> be trusted to load modules.  Some keys should be trusted to load
> specific firmware files.

No argument there.  Keys can be added to the secondary keyring that are
signed by any key on either the builtin or secondary keyrings.  We would
need to limit this to only keys that are trusted *for* are permitted to
add such *for* keys to the keyring. 

>  - The kernel only knows the public part of these keys, so there's no
> particular need to restrict who can see them, who can perform
> operations with them (there are no useful operations to perform other
> than, perhaps, "read the public key" or "try to load a module or
> firmware").

Agreed

>  - Trying to containerize them makes very little sense until someone
> proposes a resource that should be protected by such a key that might
> live in a container.

Mat Martineau posted patches that extend the concept of a trusted
keyring to userspace.  It would allow a trusted keyring (new root of
trust or based on the builtin/secondary keyrings) to be attached to a
container/namespace.

>  - There may be utility in allowing a new key to be added to the
> keyring at runtime subject to a requirement that a PCR get extended.

The builtin keyring is locked, but they could be added to the secondary
keyring.

> The keyring subsystem provides a fancy syscall interface, a fancy
> naming interface, a fancy protection interface, a fancy way to link
> keys to threads and processes, etc, none of which seems particularly
> useful here.  Using a "trusted" key for this purpose seems entirely
> pointless (we can't sign no matter what the kernel does, so what
> exactly would the TPM be protecting?). 

The terms "trust"/"trusted" are being overloaded.  There is a "trusted"
key type, which are TPM based.  Then there are "trusted" keyrings, which
require any keys being added to the keyring to be signed by a key on the
builtin/secondary keyrings.

I'm referring to the latter case of extending the secure boot of
certificate chain of trust to a set of keys, in particular the builtin
keys.  These keys can then become the root of trust for any other keys
on other keyrings.

>  The keyring subsystem is more
> about restricting *usage* of keys, not *addition* of keys.  So it's
> nice to use the keyring subsystem to add a key that grants access to a
> resource (possibly some remote server) and restrict what can be done
> with it, but the firmware/module usecase is entirely the other way
> around: we're trying to restrict which keys can be added, and we're
> allowing holders of the associated private keys to perform operations
> that affect the local machine.

Yes, from an IMA perspective, only allow files signed by a certain set
of keys to be executed.   In a container, permit files signed by a
different/additional set of keys to execute.

> May I suggest a much, much simpler approach: use a plain old struct
> list_head for each list of keys and use the crypto API directly for
> verification?  Even better, use a list of registered verifier
> callbacks where any callback in the list can say "ok, I recognize this
> proposed firmware, module, etc".  Think LoadPin but without the LSM
> baggage.  If someone really wants to use keyrings, then that facility
> could use an optional module that registers a callback that does
> exactly that.

Last year at the Linux Security Summit, Petko Manolov and Mark Baush
(Juniper) presented a very different use case scenario -
http://kernsec.org/wiki/index.php/Linux_Security_Summit_2015/Abstracts/Manolov

Mimi