James Bottomley [off-list ref] 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.

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.

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...

David