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
