RFC: 'ioctl' for keyrings

RFC: 'ioctl' for keyrings

[David Howells]

Hi Linus,

I've encountered a situation where I could do with providign certain key types
with their own operations and I'm wondering as to the best way.

The problem I've been trying to deal with is to improve quota management on
keys and introduce LRU key discard when a quota is overrun.  This requires me
to overhaul all the ->instantiate() and ->update() key type operations as they
can ask for more quota.

What I want to do is to use the preparsing mechanism I introduced for
asymmetric key handling for both operations.  This has the advantage that all
parse errors and invalid arguments can be found upfront before we start
allocating things that are difficult to back out of - and means that we're less
likely to encounter ENOMEM in the type op functions.

Now, ->instantiate() is meant to set the payload on a key and ->update() is
meant to replace the payload on a key.  There is, currently, no way to modify a
key to some lesser extent.

However, in the process of doing this, I've come to realise that the trusted
key type and the encrypted key type use their ->update() operations to make a
partial alteration to a key.

Unfortunately, this does not lend itself to preparsing because the result
depends on the key we're going to update - and we don't necessarily know the
key yet.

Further, this behaviour is also broken because ->update() may be called by
add_key() if it finds a matching key; but you cannot rely on add_key() adding
vs updating because it may race with someone else doing an add_key().  To make
matters yet more interesting, at least with encrypted_update(), the parameters
expected in the payload depend on whether you want to create a key or alter a
key.


I can fix this in one of a number of ways:

 (1) Provide a generic control operation (analogous with ioctl()) that allows
     the user to make some general operation on a key (querying it, altering
     it, interacting with hardware).

 (2) Provide an alter operation that only allows the key to be altered.
     Looking at trusted_update(), though, I have a suspicion that this may not
     be sufficient as that also seems to invoke an interaction with the TPM.

 (3) Provide separate, specific keyctl functions for the special operations
     required by encrypted and trusted keys (and other key types potentially)
     that are then validated in the core and routed to the key type.

I would prefer (2) or perhaps (3), I think.

As I understand the code, I think operations being performed from ->update()
are:

 (a) Resealing a key with a new pcrs (trusted).

 (b) Changing the master key (encrypted).

Mimi, Dmitry: is this list right?

Note that if I do provide some more appropriate vector, I will probably have to
have special code for handling encrypted and trusted keyrings in the core,
rejecting attempts to update in key_create_or_update() and redirecting them in
key_update() in security/keys/key.c

David

Re: RFC: 'ioctl' for keyrings

[David Howells]

David Howells <dhowells@redhat.com> wrote:

> I can fix this in one of a number of ways:
> 
>  (1) Provide a generic control operation (analogous with ioctl()) that allows
>      the user to make some general operation on a key (querying it, altering
>      it, interacting with hardware).
> 
>  (2) Provide an alter operation that only allows the key to be altered.
>      Looking at trusted_update(), though, I have a suspicion that this may not
>      be sufficient as that also seems to invoke an interaction with the TPM.
> 
>  (3) Provide separate, specific keyctl functions for the special operations
>      required by encrypted and trusted keys (and other key types potentially)
>      that are then validated in the core and routed to the key type.

  (4) Simply make key_update() look for the encrypted and trusted key types
      and call a special key type op for those.  The main ->update op will be
      taking preparsed data and would no longer be callable in this situation.

David

Re: RFC: 'ioctl' for keyrings

[Mimi Zohar]

On Thu, 2014-03-13 at 16:17 +0000, David Howells wrote: 
> David Howells <dhowells@redhat.com> wrote:
> 
> > I can fix this in one of a number of ways:
> > 
> >  (1) Provide a generic control operation (analogous with ioctl()) that allows
> >      the user to make some general operation on a key (querying it, altering
> >      it, interacting with hardware).
> > 
> >  (2) Provide an alter operation that only allows the key to be altered.
> >      Looking at trusted_update(), though, I have a suspicion that this may not
> >      be sufficient as that also seems to invoke an interaction with the TPM.
> > 
> >  (3) Provide separate, specific keyctl functions for the special operations
> >      required by encrypted and trusted keys (and other key types potentially)
> >      that are then validated in the core and routed to the key type.
> 
>   (4) Simply make key_update() look for the encrypted and trusted key types
>       and call a special key type op for those.  The main ->update op will be
>       taking preparsed data and would no longer be callable in this situation.

I prefer this last option. Define a separate 'update' option for trusted
and encrypted keys, which would only create or modify, but never replace
an existing key.

thanks,

Mimi

Re: RFC: 'ioctl' for keyrings

[Mimi Zohar]

On Thu, 2014-03-13 at 15:47 +0000, David Howells wrote: 
> Hi Linus,
> 
> I've encountered a situation where I could do with providign certain key types
> with their own operations and I'm wondering as to the best way.
> 
> The problem I've been trying to deal with is to improve quota management on
> keys and introduce LRU key discard when a quota is overrun.  This requires me
> to overhaul all the ->instantiate() and ->update() key type operations as they
> can ask for more quota.
> 
> What I want to do is to use the preparsing mechanism I introduced for
> asymmetric key handling for both operations.  This has the advantage that all
> parse errors and invalid arguments can be found upfront before we start
> allocating things that are difficult to back out of - and means that we're less
> likely to encounter ENOMEM in the type op functions.
> 
> Now, ->instantiate() is meant to set the payload on a key and ->update() is
> meant to replace the payload on a key.  There is, currently, no way to modify a
> key to some lesser extent.
> 
> However, in the process of doing this, I've come to realise that the trusted
> key type and the encrypted key type use their ->update() operations to make a
> partial alteration to a key.
> 
> Unfortunately, this does not lend itself to preparsing because the result
> depends on the key we're going to update - and we don't necessarily know the
> key yet.
> 
> Further, this behaviour is also broken because ->update() may be called by
> add_key() if it finds a matching key; but you cannot rely on add_key() adding
> vs updating because it may race with someone else doing an add_key().  To make
> matters yet more interesting, at least with encrypted_update(), the parameters
> expected in the payload depend on whether you want to create a key or alter a
> key.
> 
> I can fix this in one of a number of ways:
> 
>  (1) Provide a generic control operation (analogous with ioctl()) that allows
>      the user to make some general operation on a key (querying it, altering
>      it, interacting with hardware).
> 
>  (2) Provide an alter operation that only allows the key to be altered.
>      Looking at trusted_update(), though, I have a suspicion that this may not
>      be sufficient as that also seems to invoke an interaction with the TPM.
> 
>  (3) Provide separate, specific keyctl functions for the special operations
>      required by encrypted and trusted keys (and other key types potentially)
>      that are then validated in the core and routed to the key type.
> 
> I would prefer (2) or perhaps (3), I think.
> 
> As I understand the code, I think operations being performed from ->update()
> are:
> 
>  (a) Resealing a key with a new pcrs (trusted).
> 
>  (b) Changing the master key (encrypted).
> 
> Mimi, Dmitry: is this list right?

In addition to resealing trusted keys to a new TPM PCR value, there are
a few other options that can be modified (eg. keyauth, blobauth,
pcrlock).  Encrypted keys can be encrypted/decrypted with a new master
key (trusted or user key type).

Mimi

> Note that if I do provide some more appropriate vector, I will probably have to
> have special code for handling encrypted and trusted keyrings in the core,
> rejecting attempts to update in key_create_or_update() and redirecting them in
> key_update() in security/keys/key.c
> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: RFC: 'ioctl' for keyrings

[David Howells]

Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> > As I understand the code, I think operations being performed from ->update()
> > are:
> > 
> >  (a) Resealing a key with a new pcrs (trusted).
> > 
> >  (b) Changing the master key (encrypted).
> > 
> > Mimi, Dmitry: is this list right?
> 
> In addition to resealing trusted keys to a new TPM PCR value, there are
> a few other options that can be modified (eg. keyauth, blobauth,
> pcrlock).  Encrypted keys can be encrypted/decrypted with a new master
> key (trusted or user key type).

Can (re)sealing a key be viewed as encrypting it?  Is the difference between
sealing a key and encrypting a key the use of hardware support?

David

Re: RFC: 'ioctl' for keyrings

[Mimi Zohar]

On Fri, 2014-03-14 at 17:14 +0000, David Howells wrote: 
> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > > As I understand the code, I think operations being performed from ->update()
> > > are:
> > > 
> > >  (a) Resealing a key with a new pcrs (trusted).
> > > 
> > >  (b) Changing the master key (encrypted).
> > > 
> > > Mimi, Dmitry: is this list right?
> > 
> > In addition to resealing trusted keys to a new TPM PCR value, there are
> > a few other options that can be modified (eg. keyauth, blobauth,
> > pcrlock).  Encrypted keys can be encrypted/decrypted with a new master
> > key (trusted or user key type).
> 
> Can (re)sealing a key be viewed as encrypting it?  Is the difference between
> sealing a key and encrypting a key the use of hardware support?

Yes, 'resealing/sealing' is TPM terminology for encrypting/decrypting.
The sealing is RSA encryption by a TPM chip, which can only be decrypted
by the same chip.

Mimi