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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2025-06-12 at 21:36 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > One of the problems I keep tripping over is different special
> > casing for user keyrings (which are real struct key structures) and
> > system keyrings which are special values of the pointer in struct
> > key *.
> 
> It's meant to be like that.  The trusted system keyrings are static
> within system_keyring.c and not so easily accessible by kernel
> modules for direct modification, bypassing the security checks.
> 
> Obviously this is merely a bit of obscurity and enforcement isn't
> possible against kernel code that is determined to modify those
> keyrings or otherwise interfere in the verification process.

Yes, I get that, and wasn't proposing to alter it, merely make them a
bit more usable as part of the standard workflow.

Are the permissions also deliberate?  It would be useful for ordinary
users to see the certificates in there in case they want to condition
anything on signatures with internal keys.

> > For examples of what this special handling does, just look at
> > things like bpf_trace.c:bpf_lookup_{user|system}_key
> > 
> > Since the serial allocation code has a hard coded not less than 3
> > (which looks for all the world like it was designed to mean the two
> > system keyring id's were never used as user serial numbers)
> 
> That's just a coincidence.  The <3 thing predates the advent of those
> system keyring magic pointers.

Well coincidence or not it makes the scheme workable, but I've no
objection to using negatives as suggested below, either.

> > I think we could simply allow the two system keyring ids to be
> > passed into lookup_user_key() (which now might be a bit misnamed)
> > and special case not freeing it in put_key().
> 
> If you want to make lookup_user_key() provide access to specific
> keyrings like this, just use the next negative numbers - it's not
> like we're likely to run out soon.
> 
> But I'd rather not let lookup_user_key() return pointers to these
> keyrings...

That wasn't what I was proposing.  If we were to allow it I think it
would return the standard pointer that's actually simply a number as we
do now.  That would be enough to unify all the workflows into
pkcs7_verify_..() and crash soon enough if the key pointers were used
inside the kernel for stuff the system keyrings aren't supposed to do.

Regards,

James