This all looks pretty good. I'd like to see an actual list of the mdb
macros and DTrace probes that have been proposed. Furthermore, I'd like
some independent analysis from the project team (if possible) to confirm
that the new debugging enhancements can't result in leakage of sensitive
data -- whether keys (session or long term), passwords, or anything
which could be use to subvert a session or recover other sensitive
information. (I'm not doubting that the project team "did the right
thing" here -- I'd just feel better if such changes were reviewed by
other kerberos experts as an independent audit -- if this has not
already been done. (I realize that this recommendation is not
necessarily architectural -- still the sensitive nature of the software
in question merits this extra step, IMO. Also, while code review should
also be done as for any project, this independent review I'm talking
about need only consider the soundness of the interfaces and need not
delve into their implementation, IMO.)
-- Garrett
On 04/20/10 07:02 AM, Wyllys Ingersoll wrote:
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
Kerberos Diagnostic Enhancements (umbrella case)
1.2. Name of Document Author/Supplier:
Author: Shawn Emery
1.3 Date of This Document:
20 April, 2010
4. Technical Description
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2010 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Kerberos, SPNEGO, and GSS Diagnostics Enhancements (Umbrella Case)
1.2. Name of Document Author/Supplier:
Author: Shawn M. Emery
1.3 Date of This Document:
April 14, 2010
4. Technical Description
Overview
--------
Currently debugging error conditions in Kerberos and even more so in
GSS-API (Generic Security Services) application environments is very difficult.
The problem stems from the fact there are multiple layers of abstraction and
the GSS-API was not designed to provide specific error strings based on the
state of the local environment. Furthermore, some data elements are encrypted
and can only be viewed in network traces if very sensitive information is
provided by the customer.
There needs to be a better way of providing more descriptive error messages
and a way of logging additional information so that support staff can reduce
back-and-forth requests for information from the customer or to provide enough
information to the administrator to be able to take action on their own.
This is an umbrella project that covers four sub-projects for various means
of collecting and diagnosing issues:
1. Descriptive Errors Through GSS/KRB5
2. Solaris Kerberos, SPNEGO, and GSS MDB Walkers and Dcmds
3. Solaris Kerberos, SPNEGO, and GSS DTrace Probes
4. Configuration Collection
Some of the proposed solutions are specific to the S7000 environment rather
than OpenSolaris. The S7000 centric solutions include the collection of
configuration information, as the location of files, packages, and Kerberos
specific configuration is unique to the appliance's environment.
1. Descriptive Errors Through GSS/KRB5
--------------------------------------
Finer granular reporting of error conditions. Provide sufficient error
strings to the caller.
Proposal: Sync w/MIT 1.7, which contains changes for TSD messaging of
specific error strings (viz MIT ticket 5590: gss krb5 mech enhanced error
messages). gss_display_status would then be used to output the error strings.
For Kerberos API calls, krb5_get_error_message should be made and
will be documented in libkrb5(3LIB).
Note: This does not involve any interface changes besides documenting what is
already available through libkrb5 and libgss.
It would be very difficult for the mechanism to report all possible error
conditions, but an attempt to capture the most common error conditions should
be made. It is recommended to look back at old service records and CRs to
determine these common errors.
2. Solaris Kebreros, SPNEGO, and GSS MDB Walkers and Dcmds
----------------------------------------------------------
The S7000 appliance has a phone-home feature that allows services shell
access to dynamically trace issues on the system. By providing mdb
dcmds/walkers for services, one could more easily display complex structures
to diagnose problems.
The mdb modules will reside in the following directories in OpenSolaris:
usr/lib/mdb/proc/mech_krb5.so
dcmds: for user space krb5 mech
usr/lib/mdb/proc/libgss.so
dcmds: for user space GSS-API
usr/lib/mdb/proc/mech_spnego.so
dcmds: for user space SPNEGO
usr/lib/mdb/kvm/kmech_krb5.so
dcmds/walkers: for kernel space krb5 mech
usr/lib/mdb/kvm/kgssapi.so
dcmds/walkers: for kernel space GSS-API
Note: When constructing the dcmds/walkers set, it is advised that prior service
records and CRs be analyzed to determine which protocol data was useful in
determining the issue.
3. Solaris Kerberos, SPNEGO, and GSS DTrace Probes
--------------------------------------------------
The proposal is to supply DTrace user and kernel level providers to trace data
elements in the GSS/Kerberos protocol that can be logged and subsequently used
to diagnose error conditions.
- Kerberos V5, which is every part of Solaris Kerberos except the
RFC1964/4121 implementation (which excludes the code in
usr/src/lib/gss_mechs/mech_krb5/mech/ and
src/uts/common/gssapi/mechs/krb5/mech/)
- Kerberos V5 GSS-API mechanism (that is, the code in
usr/src/lib/gss_mechs/mech_krb5/mech/ and
src/uts/common/gssapi/mechs/krb5/mech/)
- SPNEGO mechanism (that is, the code in
usr/src/lib/gss_mechs/mech_spnego/mech/)
- GSS-API framework (that is, the code in usr/src/lib/libgss and the
code in usr/src/uts/common/gssapi, excluding the code in
usr/src/uts/common/gssapi/mechs)
The probes should be made compatible or contributed to the MIT Kerberos
Consortium trace logging project. The Consortium's trace logging project is
currently on their road-map here:
http://k5wiki.kerberos.org/wiki/Projects/Trace_logging
Specifically, we should use/provide the same data points (macros) as the
Consortium's, regardless of whether the back-end is DTrace or their proposed
call-back functions. Our proposed back-end will be DTrace for now.
The probes will be provided for services to turn on logging of debug
information. The interface used will be that of the dtrace(1M) provided (-P)
interface which can be accessed by the S7000's phone-home feature for services.
An application can also enable providers by libdtrace(3LIB) routines.
The provider support functions will reside here:
usr/lib/dtrace/krb5.d
usr/lib/dtrace/spnego.d
usr/lib/dtrace/gss.d
These functions will allow for a stable set of arguments to translate if/when
the Kerberos/GSS implementations change over time.
Demonstration DTrace scripts will also be provided in the /usr/demo/dtrace
directory. These scripts will provide examples for utilizing the
Kerberos/GSS/SPNEGO providers.
Note: Care will be taken not to log long term keys or session keys.
4. Configuration Collection
---------------------------
There already exists an unbundled utility to capture configuration
information. Customers can download the application, krb-diag at the
following location:
http://hub.opensolaris.org/bin/download/Project+kerberos/files/krb%2Ddiag.tar.gz
It is not in the scope of this project to bundle/productize this utility in
OpenSolaris. There have been no requests to bundle this in OpenSolaris.
Other platforms, such as the S7000, have different locations for
configuration information, therefore krb-diag does not work affectively in
those environments. The S7000 group has a separate utility, cifs-gendiag,
that collects a system's configuration:
http://blogs.sun.com/amw/entry/troubleshooting_and_diagnostics
The work here would involve converting krb-diag to work in a similar
environment as config-check, in addtion to static analysis, which krb-diag
already performs.
Interface: project private for DTrace modules and error reporting.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
_______________________________________________
opensolaris-arc mailing list
[email protected]
