lkml.org 
[lkml]   [2016]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring
From
Date
On Tue, 2016-01-12 at 02:03 +0000, David Howells wrote:

> See the patch ensubjected:
>
> [RFC PATCH 14/15] KEYS: Move the point of trust determination to __key_link()
>
> Search for keyring_alloc and particularly restrict_link_by_ima_mok.
>
> The restriction function cannot currently be cleared or modified by userspace
> - though I have an idea to make it possible to *impose* a restriction through
> keyctl() on any keyring that doesn't yet have a restriction imposed.
>
> The restriction function can impose any restrictions it likes, using the key's
> parsed payload, key type, the current keyring contents and any other keyring
> contents as it wishes in evaluating the trustworthiness of a key.

One assumption is that ima-mok is always enabled, which isn't true and
not the default. Depending on whether it is enabled, the ima keyring
would need to be restricted by "restrict_link_by_ima_mok" or
"restrict_link_by_system_trusted".

The IMA MOK and blacklist are restricted to "public_key_restrict_link".
Does this only allow keys signed by keys on the respective keyring or
also by the system keyring?

As long as the system keyring is limited to just the builtin keys, then
this looks promising. Otherwise, perhaps a separate "builtin" keyring
should be defined.

Mimi

\
 
 \ /
  Last update: 2016-01-12 05:21    [W:2.003 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site