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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e0f91ae1e43dbb05b97c248cd09fb0030e041f51.camel@HansenPartnership.com>
Date: Fri, 13 Jun 2025 11:40:51 -0400
From: James Bottomley <James.Bottomley@...senPartnership.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 Thu, 2025-06-12 at 21:36 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@...senPartnership.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