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

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

On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> Hi Andy,
> 
> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski 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.
> > 
> >  - Keys should specify what they're trusted *for*.
> 
> Well, I'd argue that keys should specify what they are *intended* for by
> the keyholder.  A useful security system could further restrict the key
> as needed.

We've already started.  Currently the kernel_read_file() and family of
functions provide the LSM hooks needed for verifying file signatures of
files read by the kernel.  The kernel_read_file_id enumeration is used
to differentiate between callers.  Based on this enumeration, the
*intended* for could be defined.  It would make sense to extend the IMA
policy language to support *intended* for.

Mimi

> e.g. the Microsoft key may say it's intended for "Verifying binaries
> issued by Microsoft".  A Linux user would want to restrict that to
> verifying updated boot shims for UEFI.
> 
> If nothing else, we need to grok the lessons learned from the CA
> system.
> 
> > Some keys should be trusted to load modules.  Some keys should be
> > trusted to load specific firmware files.
> 
> "Some keys should be restricted to verifying modules.  Some keys should
> be restricted to verifying specific firmware files." [0]
> 
> We'll know the system is designed correctly if we don't mind the
> Microsoft key being in the keyring.
> 
> There's definitely a larger conversation to be had here.  The Kernel is
> a *part* of the system, and should be a *part* of the security of the
> system.  Attempting to make it the whole enchilada risks making the same
> design errors as TrustZone.  "Just put all your eggs in this *other*
> basket.  No one can see in it, but it has access to everything on the
> system.  Oh, you have proprietary, complicated, un-reviewed DRM code
> that parses unsanitized input?  Sure, put it in there with the key
> manager.  No problem, it's magic."  Moving cheese. [1]
> 
> thx,
> 
> Jason.
> 
> [0] A wise man once told me to avoid the word 'trust' in conversations
> about security.  It's a vague term whose meaning varies from person to
> person and from situation to situation.
> 
> [1] https://bits-please.blogspot.de/2016/06/extracting-qualcomms-keymaster-keys.html
>