Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iffc1478b:Fastmail
Date:   Mon, 24 Apr 2023 10:23:09 -0400
From:   Ben Boeckel <me@benboeckel.net>
To:     Scott Mayhew <smayhew@redhat.com>
Cc:     linux-nfs@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [RFC PATCH 5/5] SUNRPC: store GSS creds in keyrings
Message-ID: <20230424142309.GB1072182@farprobe>
References: <20230420202004.239116-1-smayhew@redhat.com>
 <20230420202004.239116-6-smayhew@redhat.com>
 <20230422212710.GA813856@farprobe>
 <ZEaL8Wueo5/vOGTg@aion.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZEaL8Wueo5/vOGTg@aion.usersys.redhat.com>
User-Agent: Mutt/2.2.9 (2022-11-12)
Precedence: bulk

On Mon, Apr 24, 2023 at 10:02:25 -0400, Scott Mayhew wrote:
> On Sat, 22 Apr 2023, Ben Boeckel wrote:
> > What is the format of this within the bytes?
> 
> The format is "clid: <client-id> id: <fsuid> princ:<princ>", where
> client-id and fsuid are unsigned ints and princ is either "(none)" or
> "*" if it's a machine cred:
> 
> crash> p ((struct key *) 0xffff8b4410197900)->description
> $1 = 0xffff8b4446cbd740 "clid:1 id:1000 princ:(none)"

Thanks. A bit annoying to parse, but doable.

> > > - The key payload contains the address of the gss_cred.
> > 
> > What is the format of this within the bytes?
> 
> The payload is just a pointer:
> 
> crash> p ((struct key *) 0xffff8b4410197900)->payload.data[0]
> $2 = (void *) 0xffff8b44381cd480

This looks less useful to userspace (beyond some kind of unique
ID…though can it be used to extract information about ASLR or any other
security mechanism?). Can userspace somehow write to this payload to
confuse things at all?

I'm no security expert so this is just a "random idea" to at least
hopefully trigger Cunningham's Law, but storing it `xor`'d with some
per-boot secret could help muddle any information
leak/extraction/targeting usefulness.

> > > - The key is linked to the user's user keyring (KEY_SPEC_USER_KEYRING)
> > >   as well as to the keyring on the gss_auth struct.
> > 
> > Where is this documented? Can the key be moved later?
> 
> It's not - I can add that to the documentation for the new key type.
> The key should not be moved.  I haven't tested if it's possible to move
> it, but it's something that we'd want to disallow.

If it shouldn't be unlinked that's one thing, there's still the
possibility of also linking it from another keyring (I don't see why
that should be a problem at least).

Also, to be clear I was talking about the `KEY_SPEC_USER_KEYRING`
keyring. Keeping it in the `gss_auth`'s keyring makes 100% sense (though
if there's no way to keep it there, that seems like a corner case that
would need considered).

Thanks,

--Ben