[RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits

[RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits

[David Howells]

Hi Marcel, Mimi, Tadeus,

I want to consider adding or doing the following bits to the keyrings
facility, aiming for the next merge window:

 (*) Bring in the patches that I posted to change how the trust model on a
     keyring works.

     The model will then be that keys aren't automatically marked trusted, but
     linking a key into a keyring that is marked trusted-only will validate
     the key against the contents of the keyring before permitting its
     addition.

     Note that we can then vary the policy on a per-keyring basis.

 (*) Add Mimi's patches to allow keys/keyrings to be marked undeletable.  This
     is for the purpose of creating blacklists and to prevent people from
     removing entries in the blacklist.  Note that only the kernel can create
     a blacklist - we don't want userspace generating them as a way to take up
     kernel space.

     I think the right way to do this is to not allow marked keys to be
     unlinked from marked keyrings, but to allow marked keys to be unlinked
     from ordinary keyrings.

     The reason the 'keep' mark is required on individual keys is to prevent
     the keys from being directly revoked, expired or invalidated by keyctl
     without reference to the keyring.  Marked keys that are set expirable
     when they're created will still expire and be subsequently removed and if
     a marked key or marked keyring loses all its references it still gets
     gc'd.

 (*) Provide KEYCTL_{SIGN,VERIFY,ENCRYPT,DECRYPT} operations for use with
     asymmetric keys, allowing offload to hardware or use of the crypto
     routines for a software fallback.

     One question is as to how to set parameters.  The key will be specified
     by a key ID and this will set the crypto algorithm (eg. RSA, DSA, ECDSA,
     etc.) and the key size (eg. RSA-4096), but other parameters will need to
     be supplied such as:

     - Hash type.  I'm expecting the hash value to be passed through this
       interface not the data-to-be-hashed, but the type may need to be known
       for other purposes.

     - Password to decrypt the private key.  I'm not sure whether this should
       be presented at the point of key usage or the point of key
       instantiation.  The former means that you don't have an unsecured key
       sitting around in the kernel.

     Another question is what form the data should be presented.  In many
     ways, I would favour raw data with internal metadata attached as
     appropriate by userspace (eg. the hash algorithm OID included in a
     signature as per RFC4880 sec 5.2.2).  I would certainly rather avoid any
     ASN.1 or PGP encodings in this interface.

     One problem we have is that we only have four arguments to play with, one
     of which has to represent the key ID, but we need two buffers, two buffer
     lengths and some options per operation.  However, we could include the
     buffer lengths inside the options maybe:

	keyctl_sign(int key, const char *options, const void *data,
	            void *buffer);

     Another option is to allow a key to be queried for the buffer sizes and
     always require that amount of data - maybe something like:

	struct keyctl_asymmetric_info {
		unsigned encrypted_data_size;
		unsigned decrypted_data_size;
		unsigned signature_size;
		unsigned signed_data_size;
	} info;
	keyctl_query_asymmetric(key, &info);

     Possibly these values will all be the same, so we might only need get one
     value back.  I'm assuming here that userspace would do the dressing up of
     the data for signing with whatever metadata and padding is required.

 (*) In reference to the above, potentially provide a KEYCTL_KEY_UNLOCK that
     takes a key and password and gives you another key that has the private
     key unlocked that you can use temporarily and then discard.  I'm not sure
     how best to manage *hardware* private keys though - and I suspect that
     will be hardware dependent.

 (*) A TPM asymmetric key subtype that allows access to asymmetric keys stored
     in a TPM.

 (*) Provide KEYCTL_SEAL_KEY for sealing an asymmetric key to hardware.

 (*) Add a symmetric key type that acts as a container for a symmteric key,
     using either hardware or software, to be accessible through AF_ALG.

 (*) Provide a way to generate a new symmetric key, encrypting it with an
     asymmetric key inside the kernel.

     Again, how to parameterise is probably a tricky question.

 (*) Sort out the KEYCTL_UPDATE mess with trusted and encrypted keys.

David

Re: [RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits

[Mimi Zohar]

On Fri, 2015-11-20 at 11:07 +0000, David Howells wrote:
> Hi Marcel, Mimi, Tadeus,
> 
> I want to consider adding or doing the following bits to the keyrings
> facility, aiming for the next merge window:
> 
>  (*) Bring in the patches that I posted to change how the trust model on a
>      keyring works.
> 
>      The model will then be that keys aren't automatically marked trusted, but
>      linking a key into a keyring that is marked trusted-only will validate
>      the key against the contents of the keyring before permitting its
>      addition.

This trust model is flawed.   We've already discussed this trust model
back when first introducing the concept of a trusted keyring.   Refer to
the v3 "ima: extending secure boot certificate chain of trust" patch set
https://lwn.net/Articles/576563/, which describes two methods of
verifying a certificate before adding the key to the trusted keyring.  

The first method  "4/5 KEYS: verify certificate is signed by a trusted
key on the target keyriing" is similar to the method being proposed
here.  The subsequent patch "5/5 KEYS: verify certificate is signed by a
trusted key on a particular keyring" rejected using the same keyring for
validating the new key being added.  It defined a new separate keyring
for validating the keys.  (Neither of these patches were upstreamed.)

Dmitry Kasatkin proposed a third method, which identified the "trusted"
key(s) on the system keyring, instead of maintaining a separate keyring.
As there wasn't a usecase requiring a separate keyring at the time, his
approach was upstreamed.  Now Petko Manoliv and Mark Bausche  have a
valid use case scenario for having a separate keyring.  (For the details
refer to:
https://www.mail-archive.com/linux-security-module@vger.kernel.org/msg03503.html)

With the proposed trust model change, the keys trusted to verify file
signatures would be allowed to also verify certificate signatures.  For
example, a system owner trusts company A to verify file signatures, yet
they want to retain control over which certificates may be added to the
keyring.  Just because company A trusts company/government X, doesn't
mean the system owner also trusts company/government X.   By having one
keyring, other certificates signed by company A could be added to the
keyring.

>      Note that we can then vary the policy on a per-keyring basis.
> 
>  (*) Add Mimi's patches to allow keys/keyrings to be marked undeletable.  This
>      is for the purpose of creating blacklists and to prevent people from
>      removing entries in the blacklist.  Note that only the kernel can create
>      a blacklist - we don't want userspace generating them as a way to take up
>      kernel space.
> 
>      I think the right way to do this is to not allow marked keys to be
>      unlinked from marked keyrings, but to allow marked keys to be unlinked
>      from ordinary keyrings.
> 
>      The reason the 'keep' mark is required on individual keys is to prevent
>      the keys from being directly revoked, expired or invalidated by keyctl
>      without reference to the keyring.  Marked keys that are set expirable
>      when they're created will still expire and be subsequently removed and if
>      a marked key or marked keyring loses all its references it still gets
>      gc'd.

Agreed.  I'll fix and re-post soon.

Mimi

Re: [RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits

[Mimi Zohar]

On Sun, 2015-11-22 at 09:41 -0500, Mimi Zohar wrote:
> On Fri, 2015-11-20 at 11:07 +0000, David Howells wrote:
> > 
> >  (*) Add Mimi's patches to allow keys/keyrings to be marked undeletable.  This
> >      is for the purpose of creating blacklists and to prevent people from
> >      removing entries in the blacklist.  Note that only the kernel can create
> >      a blacklist - we don't want userspace generating them as a way to take up
> >      kernel space.
> > 
> >      I think the right way to do this is to not allow marked keys to be
> >      unlinked from marked keyrings, but to allow marked keys to be unlinked
> >      from ordinary keyrings.
> > 
> >      The reason the 'keep' mark is required on individual keys is to prevent
> >      the keys from being directly revoked, expired or invalidated by keyctl
> >      without reference to the keyring.  Marked keys that are set expirable
> >      when they're created will still expire and be subsequently removed and if
> >      a marked key or marked keyring loses all its references it still gets
> >      gc'd.
> 
> Agreed.  I'll fix and re-post soon.

In addition to Petko's 3 patches, the ima-keyrings branch
(git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git) contains these two patches.

d939a88 IMA: prevent keys on the .ima_blacklist from being removed
77f33b5 KEYS: prevent keys from being removed from specified keyrings

As the IMA patch is dependent on the KEYS patch, do you mind if the KEYS
patch would be upstreamed together with this patch set?

Mimi