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