Linux NFS development
 help / color / mirror / Atom feed
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
Date: Mon, 24 Apr 2023 10:23:09 -0400	[thread overview]
Message-ID: <20230424142309.GB1072182@farprobe> (raw)
In-Reply-To: <ZEaL8Wueo5/vOGTg@aion.usersys.redhat.com>

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

  reply	other threads:[~2023-04-24 14:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-20 20:19 [RFC PATCH 0/5] SUNRPC: Add option to store GSS credentials in Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 1/5] keys: export keyring_ptr_to_key() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 2/5] keys: add keyring_gc_custom() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 3/5] keys: add dest_keyring parameter to request_key_with_auxdata() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 4/5] keys: add the ability to search user keyrings in search_cred_keyrings_rcu() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 5/5] SUNRPC: store GSS creds in keyrings Scott Mayhew
2023-04-22 21:27   ` Ben Boeckel
2023-04-24 14:02     ` Scott Mayhew
2023-04-24 14:23       ` Ben Boeckel [this message]
2023-04-24 15:01         ` Scott Mayhew
2023-04-24 18:28           ` Ben Boeckel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230424142309.GB1072182@farprobe \
    --to=me@benboeckel.net \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=smayhew@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox