Re: [Linux-ima-devel] [PATCH v3 0/5] Make keyring link restrictions accessible from userspace

[Mimi Z. <zo...@li...>]

Cc'ing the linux-ima-devel mailing list ...

On Wed, 2016-06-15 at 15:55 -0700, Mat Martineau wrote:
> On Wed, 15 Jun 2016, Mimi Zohar wrote:
> 
> > On Tue, 2016-06-14 at 15:09 -0700, Mat Martineau wrote:
> >> Keyrings recently aquired the ability to validate keys before they are
> >> linked, but keyrings created from userspace with the add_key syscall
> >> could not configure keyrings to do so. This patch set enables creation
> >> of restricted keyrings from userspace.
> >>
> >> Open questions from v2 discussion:
> >>
> >>  * Is the approach to sharing code between restrict_link_by_signature and
> >>    restrict_link_by_signature_indirect acceptable? (Patch 2/5)
> >
> > I'm really opposed to this change.
> 
> I will decouple these functions.

Validating keys against a specific key (or a set of keys on a keyring)
AND extending the secure boot signature chain of trust to a userspace
keyring should both be supported.  Your patches only support the first
not the latter.  The latter is just as important, if not more so.

Instead of removing ca_keyid and use_builtin_keys consider making them
keyring specific.*  The ca_keyid limits signature checking to a single
key.  If ca_keyid was not global but keyring specific, could this be
used for implementing restrict_link_by_key?  Similarly, making
use_builtin_keys keyring specific could be used to extend the signature
chain of trust to some, but not all userspace keyrings.

* I'm not sure if it is possible with the current architecture or how
difficult it would be to make them keyring specific.

> >>  * Is an additional restriction method needed that allows verification
> >>    of new keys using the existing keys in the keyring? If so, is that
> >>    needed in this patch set or can it be a follow-on?
> >
> > I can definitely see a use case for only allowing certificates signed by
> > a particular key to be added to a userspace keyring (eg.
> > restrict_link_by_key) or by only allowing certificates signed by any key
> > on the target keyring (eg. restrict_link_by_self).  Either of these
> > functions would be needed in this patch set.
> 
> Since the restrict method is set when the (empty) keyring is created, I 
> need to figure out a way to bootstrap a keyring that uses 
> restrict_link_by_self. Does one of these sound good?
> 
>   * Initially populate the keyring without verifying signatures. After the 
> user sets a flag on the keyring, check signatures on all further link 
> operations.

This would be similar to the KEY_ALLOC_BYPASS_RESTRICTION flag, which is
used for loading the builtin keys onto the builtin trusted keyring.
Intentionally, the KEY_ALLOC_BYPASS_RESTRICTION flag is NOT exported to
userspace.

>   * Do not check signature for first key linked, then check future 
> signatures based on the key(s) in the keyring.

If the first key was signed by a key on the builtin trusted keyring,
this would then extend the secure boot signature chain of trust to the
userspace keyring.  Yet, the trust in the keys added to the userspace
keyring would be limited to the particular keyring's usage.

Mimi