Messages in this thread | | | Date | Tue, 8 Mar 2016 18:37:58 +0200 | From | Petko Manolov <> | Subject | Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2] |
| |
On 16-03-08 16:07:00, David Howells wrote: > Petko Manolov <petkan@mip-labs.com> 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
| |