GSSAPI security context integrity check

[Alexandr Nedvedicky]

On Wed, May 06, 2020 at 08:26:57PM -0400, Greg Hudson wrote:
</snip>
> > Customer switched to Solaris 11.4, which comes with kerberos
> > 1.16.
> 
> Are there Solaris-specific modifications to this code, or is it
> unmodified 1.16?

    sorry I've forgot to mention that in my first email. There are
    several modifications to GSSAPI. Although those changes do
    touch the GSSAPI, they should not matter (according to my
    guess/understanding of code).

    The first change improves interoperability with SMB [1]. According
    to records it dates back to WinXP epoch.

    There are also Solaris specific modifications, which allow MIT
    kerberos to share security context with keberos mechanism implemented
    in Solaris kernel [2]. If I understand things right, they allow kerberized
    NFS to work.

    then there is change, which deals with specific way to acquire
    credentials for the root user [3].

    The remaining changes deal with source code compatibility
    for legacy parts of Solaris.

> 
> > two security contexts attempted to use integrity protection.
> 
> The two filenames had the same suffix (c523660).  If I understand
> correctly, that is the pointer value of the krb5 GSS context object--so
> both g_seqstate_init() calls were for the same context (which is
> consistent with the initial sequence numbers being the same).  It would
> be very interesting to know the stack traces of the two
> g_seqstate_init() calls, although that might be difficult to collect
> remotely.  Normally there should only be one g_seqstate_init() call for
> a context, from kg_accept_krb5().

    I'll ask customer to collect the stack with dtrace. After spending couple
    days browsing through source code the g_seqstate_init() gets only called
    when new security context is born (import, accept or init).

    Assuming I interpret the log from SAPware right, we run as GSS acceptor,
    so g_seqstate_init() is being called from kg_accept_krb5() in
    lib/gssapi/krb5/accept_sec_context.c.

yes, that's a good idea to try to collect stack trace using dtrace.

thanks and
regards
sasha

[1] https://github.com/Sashan/krb5/commit/fa78fb2c9f6e92e087b27c86c1fa79326fde73b5

[2] https://github.com/Sashan/krb5/commit/43ce4ff37598e91f7ae35630115bfcec5bbe6eb7

[3] https://github.com/Sashan/krb5/commit/5373d32f0d2f323e42dabec02707f591a3ae10fc