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
