Message-ID: <D33BA76E-E2D3-42C8-A983-A733ECD71CCE@redhat.com>
Date: Thu, 12 Jun 2025 10:10:34 -0400
From: Benjamin Coddington <bcodding@...hat.com>
To: David Howells <dhowells@...hat.com>
Cc: keyrings@...r.kernel.org, Jarkko Sakkinen <jarkko@...nel.org>,
 Steve French <sfrench@...ba.org>, Chuck Lever <chuck.lever@...cle.com>,
 Mimi Zohar <zohar@...ux.ibm.com>, Paulo Alcantara <pc@...guebit.org>,
 Herbert Xu <herbert@...dor.apana.org.au>,
 Jeffrey Altman <jaltman@...istor.com>, hch@...radead.org,
 linux-afs@...ts.infradead.org, linux-nfs@...r.kernel.org,
 linux-cifs@...r.kernel.org, linux-security-module@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-crypto@...r.kernel.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Keyrings: How to make them more useful

On 12 Jun 2025, at 8:36, 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.
>
>  (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.
>
>  (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.
>
>  (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.

Indeed one challenge on this front is configuring how to stitch together the
various callers and recievers especially when one wants an upcall from one
set of namespaces to be serviced within another.

I had previously posted some work in this area that fleshes out the idea of
a "key agent" which is a userspace process that can receive a notification
to instantiate a key.  The nice part (IMO) of this idea is that the keyagent
is represented by a key itself, so the channel is available to any process
that has the keyagent key in their keyrings.

This allows a system to have a single keyagent for all processes/namespaces
for a particular key type, or to build a more granular configuration where
agents are confined within the same (or different) namespaces as the calling
process.

I'd be happy to continue work on this front, since long-term it would allow
us to convert various NFS upcall mechanisms such that NFS access within a
container wouldn't require duplicated gssd/svcgssd/idmapper userspace
processes in every container if all the system needed was to use a single
global instance.  It would also allow the partitioning of secure
cryptographic material (like keytabs and certificate secrets) from
containers that might still want to use NFS, but not divulge those secrets
to the processes in that container.

Ben

Powered by blists - more mailing lists