On Thu, 2025-06-12 at 21:36 +0100, David Howells wrote:

James Bottomley [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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