Re: [RFC] Keyrings: How to make them more useful

[Jarkko Sakkinen <jarkko@kernel.org>]

On Thu, Jun 12, 2025 at 01:36:50PM +0100, David Howells wrote:
> Hi Jarkko, Steve, Chuck, Mimi, et al.,
> 
> I think work needs to be done on the keyrings subsystem to make them more
> useful for network filesystems and other kernel services such as TLS and
> crypto.
> 
> There are a number of issues that I think need addressing:
> 
>  (1) One of the flaws in the initial design is that whilst keys have a type
>      (which is necessary), this has to be specified as part of the lookup or
>      the search, which is overly restrictive.
> 
>      It probably would have been better to search by description alone and
>      then, if a key is found, have any type of key with that description
>      returned and let the app/service investigate the key to find the type.
> 
>      Now, this is still possible to implement on top of the existing API: just
>      allow a NULL type to be passed in - but we might need some way to
>      enumerate all the keys with that description, but of different types.
>      Possibly, the search function should return all the matching keys.
> 
>      Possibly, within the kernel, for each keyring, all the keys of the same
>      description can be stored within a group structure, and the search
>      returns the group.  This could also have the added benefit of maybe
>      making it easier to handle updates.

All keys matching the description can be collected by iterating all the
key types (instead of passing NULL).

Having only a syscall for the process has of course much better
concurrency properties.  Just trying to understand the improvements by
actual measure, that's all.

>  (2) For certain applications, keys need versioning - and we need to be able
>      to get access to older versions (at least to some extent) of the keys.
>      An example of this is cifs where (if I understand it correctly) the key
>      version gets cranked, but not all servers may have caught up yet, so we
>      need to be able to try the keys in descending order of version.
> 
>      This could also work within the group idea mentioned above.
> 
>  (3) For certain applications, such as AFS and AF_RXRPC, we may need to be
>      able to keep a number of keys around that have the same description
>      (e.g. cell name) and basic type (e.g. rxrpc) and version, but that have
>      different crypto types (e.g. Rx security classes and Kerberos types, such
>      as RxGK+aes256-cts-hmac-sha1-96, RxGK+aes128-cts-hmac-sha256-128 or
>      RxKAD) as different servers in the same cell might not support all or we
>      might be implementing a server that is offering multiple crypto types.
> 
>      So we might need a "subtype" as well as a version.

1. How the history is capped? I presume it is a fixed-size circular
   buffer, where the oldest entry is deleted, when the key is updated.
1. How history queried by the caller?
2. How a newer version is revoked in favor of a newer version?

>  (4) I think the keyring ACLs idea need to be revived.  We have a whole bunch
>      of different keyrings, each with a specific 'domain' of usage for the
>      keys contained therein for checking signatures on things.  Can we reduce
>      this to one keyring and use ACLs to declare the specific purposes for
>      which a key may be used or the specific tasks that may use it?  Use
>      special subject IDs (ie. not simply UIDs/GIDs) to mark this.

Is subject ID some kind of token that a process can hold (and possibly
can be sent to a process)?

> 
>  (5) Replace the upcall mechanism with a listenable service channel, so that a
>      userspace service (possibly part of systemd or driven from systemd) can
>      listen on it and perform key creation/maintenance services.
> 
>      From previous discussions with the systemd maintainer, it would be a lot
>      easier for them to manage if the key is attached to a file descriptor -
>      at least for the duration of the maintenance operation.
> 
>      Further, this needs to be containerised in some way so that requests from
>      different containers can be handled separately - and can be
>      distinguished

This sounds like an universally sane idea (outside the scope of the
patch set).

> 
>  (6) Move away from keeping DNS records in a keyring, but rather keep them in
>      some sort of shrinkable list.  They could still be looked up over a
>      secure channel.

Don't expertise to understand the benefits of this change. 


> 
> To aid with at least (1), (2) and (3) and possibly (4), I think it might be
> worth adding an extended add_key() system call that takes an additional
> parameter string:
> 
> 	key_serial_t add_key2(const char *type,
> 			      const char *description,
> 			      const char *parameters,
> 			      const void payload, size_t plen,
> 			      key_serial_t keyring);
> 
> The parameters would get passed to the key type driver for it to extract
> things like version number and subtype from without the need to try and fold
> it into the payload (which may, for example, be a binary ticket obtained from
> kerberos).  Though possibly that is a bad example as the kerberos ticket may
> contain multiple keys.

Does the parameter list mimic kernel command-line style of comma
separated attributes?

BR, Jarkko