[20142] in Kerberos_V5_Development
Re: GSSAPI security context integrity check
daemon@ATHENA.MIT.EDU (Alexandr Nedvedicky)
Sun Jun 28 02:20:50 2020
Date: Sun, 28 Jun 2020 08:17:16 +0200
From: Alexandr Nedvedicky <alexandr.nedvedicky@oracle.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20200628061716.GW2891@tbd>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f5b1d259-ec55-09e9-c55b-344957b77259@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, Jun 26, 2020 at 11:38:10AM -0400, Greg Hudson wrote:
> On 6/26/20 4:10 AM, Alexandr Nedvedicky wrote:
> > Once issue was understood the fix is straightforward. The export/import
> > process must serialize security context such it will be compatible with kernel
> > mechanism (turn seqstate to order). And vice-versa import process must turn
> > order to seqstate. End of story.
>
> Thanks for the update; it provides a lot of useful context.
>
> We have periodically talked about radically changing how gss-krb5
> security contexts are exported and imported, most likely accompanied by
> a written specification. That would let us rip out the libkrb5
> serialization code (which isn't up to current standards), perhaps share
> a token format with Heimdal, and most likely reduce the token size
> significantly.
>
> It sounds like if we did this work, it would create a significant amount
> of work for Oracle, which would have to either translate the new format
> to the kernel format, or adapt the import code to the kernel. On the
> other hand, if the new format is stable and/or versioned, it might help
> to prevent subtle bugs like this one--which was caused by a change to
> the export token format without any accompanying versioning.
To be honest I had no time to figure out all details around
krb5 kernel mechanism in Solaris. I was thinking about updating the
kernel mechanism with newer bits from upstream. But I feel kind of
scared to do it. There is just NFS test suite, which provides coverage
and I'm just afraid it might not be enough. The resources are bit
stretched these days. It used to be 4-5 developers to take care of one
component such as kerberos. The ratio is kind of inverted after all lay
offs in our org.
I think 'significant work for Oracle' should not matter. If the API
will provide some extra belts. This particular bug was sitting there
waiting to bite us for almost 5 years without being noticed.
thanks and
regards
sasha
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
