On 16-03-08 16:07:00, David Howells wrote:
> Petko Manolov <[email protected]> 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.
I don't have strong opinions against (2). This is more of a discussion whether
we should sacrifice in favor of simplicity or flexibility.
> Remember - these keyrings aren't necessarily restricted to IMA.
I am well aware of that. At some point (perhaps not now) i'd like to discuss
allowing kernel module loading based on keys in the secondary keyring. It is a
niche feature for those machines that have uptime measured in years. I
certainly don't expect it to be something the regular desktop or embedded users
need.
Another issue that we left unresolved is the system-wide blacklist keyring. It
is at the same hierarchy level as the secondary keyring and serves a similar
purpose although in opposite direction.
Petko
