Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

[Mimi Zohar]

On Tue, 2016-03-08 at 18:37 +0200, Petko Manolov wrote:
> On 16-03-08 16:07:00, David Howells wrote:
> > Petko Manolov <petkan@xxxxxxxxxxxx> wrote:
> > 
> > > > How about I change it to a choice-type item, with the following options:
> > > > 
> > > >  (1) No addition.
> > > > 
> > > >  (2) Addition restricted by built-in keyring.
> > > > 
> > > >  (3) Addition restricted by secondary keyring + built-in keyring.
> > > > 
> > > > where the second and third options then depend on the appropriate keyrings 
> > > > being enabled.
> > > 
> > > I would suggest leaving (1) and (3).  Since secondary keyring only accepts
> > > keys signed by certificate in the system keyring I think (2) is redundant.
> > > It adds extra complexity (Kconfig is vague enough already) while it doesn't
> > > increase the overall security by much.
> > 
> > If I remove option (2), that would mean that if you want to allow keys to be 
> > added to .ima if they're signed by the built-in keyring, then you also allow 
> > keys to be added to .ima if they're signed by the secondary keyring if 
> > enabled.
> 
> Exactly.  The primary difference between the built-in and secondary keyring is 
> that the latter is R/W.  Chances are the user want either no addition or need 
> dynamic key add/remove.

Option 1 will prevent ANY keys from being added to the IMA keyring that
were not builtin and loaded by the kernel, similar to the existing
system certificate list.  The keyring itself would need to allow the
builtin keys to be added with the "KEY_ALLOC_BYPASS_RESTRICTION"
override.

Option 2 only allows certificates signed by a key on the builtin keyring
to be added to the IMA keyring.  (This should be the default.)

> I don't have strong opinions against (2).  This is more of a discussion whether 
> we should sacrifice in favor of simplicity or flexibility.

I disagree.  There is a major difference between option 2 and 3.

Mimi