From wyllys@borg.sfbay.sun.com Tue Apr 20 07:03:19 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3KE3IYE019479 for ; Tue, 20 Apr 2010 07:03:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3KE3HKv017508 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Tue, 20 Apr 2010 07:03:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1600C2HHPG1900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 20 Apr 2010 07:03:16 -0700 (PDT) Received: from borg.sfbay ([10.5.240.20]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L16001U3HPCEYE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 20 Apr 2010 07:03:13 -0700 (PDT) Received: from borg.sfbay (localhost [127.0.0.1]) by borg.sfbay (8.14.4+Sun/8.14.4) with ESMTP id o3KE2wvq009790; Tue, 20 Apr 2010 07:02:58 -0700 (PDT) Received: (from wyllys@localhost) by borg.sfbay (8.14.4+Sun/8.14.4/Submit) id o3KE2uTQ009770; Tue, 20 Apr 2010 07:02:56 -0700 (PDT) Date: Tue, 20 Apr 2010 07:02:56 -0700 (PDT) From: Wyllys Ingersoll Subject: Kerberos Diagnostic Enhancements (umbrella case) [PSARC/2010/135 FastTrack timeout 04/27/2010] To: PSARC-ext@sun.com Cc: shawn.emery@oracle.com Message-id: <201004201402.o3KE2uTQ009770@borg.sfbay> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7603 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 From garrett.damore@oracle.com Tue Apr 20 08:15:20 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3KFFFvM021380 for ; Tue, 20 Apr 2010 08:15:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3KFF8oK011329 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 20 Apr 2010 10:15:09 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1600F0PL19M400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Apr 2010 08:15:09 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1600DUBL18SG60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Apr 2010 08:15:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3KFF7HW003428; Tue, 20 Apr 2010 15:15:07 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3KB4IFW005999; Tue, 20 Apr 2010 15:15:03 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 191588701271776496; Tue, 20 Apr 2010 08:14:56 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Apr 2010 08:14:55 -0700 Date: Tue, 20 Apr 2010 08:14:54 -0700 From: "Garrett D'Amore" Subject: Re: Kerberos Diagnostic Enhancements (umbrella case) [PSARC/2010/135 FastTrack timeout 04/27/2010] In-reply-to: <201004201402.o3KE2uTQ009770@borg.sfbay> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, shawn.emery@oracle.com Message-id: <4BCDC4EE.9020908@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BCDC4F9.00CE:SCFMA4539814,ss=1,fgs=0 References: <201004201402.o3KE2uTQ009770@borg.sfbay> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 9083 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 > > From Mark.Phalan@Sun.COM Tue Apr 20 08:27:46 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3KFRaaT021627 for ; Tue, 20 Apr 2010 08:27:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3KFRZkH004826 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 20 Apr 2010 08:27:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1600G0JLLZA100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Apr 2010 08:27:35 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1600DS6LLYSE70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Apr 2010 08:27:34 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3KFRXh0015332 for ; Tue, 20 Apr 2010 15:27:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1600J00KE05D00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Apr 2010 16:27:16 +0100 (BST) Received: from [129.157.251.72] ([unknown] [129.157.251.72]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1600DBULL0SV00@fe-emea-10.sun.com>; Tue, 20 Apr 2010 16:27:02 +0100 (BST) Date: Tue, 20 Apr 2010 17:27:00 +0200 From: Mark Phalan Subject: Re: Kerberos Diagnostic Enhancements (umbrella case) [PSARC/2010/135 FastTrack timeout 04/27/2010] In-reply-to: <4BCDC4EE.9020908@oracle.com> Sender: Mark.Phalan@Sun.COM To: "Garrett D'Amore" Cc: Wyllys Ingersoll , PSARC-ext@Sun.COM, shawn.emery@oracle.com Message-id: <1271777220.4577.2.camel@phalan> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004201402.o3KE2uTQ009770@borg.sfbay> <4BCDC4EE.9020908@oracle.com> Status: RO Content-Length: 1306 On Tue, 2010-04-20 at 08:14 -0700, Garrett D'Amore wrote: > This all looks pretty good. I'd like to see an actual list of the mdb > macros and DTrace probes that have been proposed. Expect more cases exposing the Dtrace probes (soon) and MDB macros (later). > 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.) I think that this concern can be followed up in the cases which will introduce the probes and macros. -M From garrett.damore@oracle.com Tue Apr 20 09:08:56 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3KG8pr0022251 for ; Tue, 20 Apr 2010 09:08:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3KG8glp010126; Tue, 20 Apr 2010 10:08:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1600A11NIKFD00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Apr 2010 09:08:44 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L16003OWNIJTWA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Apr 2010 09:08:43 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3KG8ghl012924; Tue, 20 Apr 2010 16:08:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3KG8fgn009385; Tue, 20 Apr 2010 16:08:41 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 174694541271779708; Tue, 20 Apr 2010 09:08:28 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Apr 2010 09:08:28 -0700 Date: Tue, 20 Apr 2010 09:08:26 -0700 From: "Garrett D'Amore" Subject: Re: Kerberos Diagnostic Enhancements (umbrella case) [PSARC/2010/135 FastTrack timeout 04/27/2010] In-reply-to: <1271777220.4577.2.camel@phalan> To: Mark Phalan Cc: Wyllys Ingersoll , PSARC-ext@sun.com, shawn.emery@oracle.com Message-id: <4BCDD17A.10702@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BCDD18A.0065:SCFMA4539814,ss=1,fgs=0 References: <201004201402.o3KE2uTQ009770@borg.sfbay> <4BCDC4EE.9020908@oracle.com> <1271777220.4577.2.camel@phalan> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1887 On 04/20/10 08:27 AM, Mark Phalan wrote: > On Tue, 2010-04-20 at 08:14 -0700, Garrett D'Amore wrote: > >> This all looks pretty good. I'd like to see an actual list of the mdb >> macros and DTrace probes that have been proposed. >> > Expect more cases exposing the Dtrace probes (soon) and MDB macros > (later). > > >> 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.) >> > I think that this concern can be followed up in the cases which will > introduce the probes and macros. > Ok, so then the specification for those are *not* part of this case, and I'm happy with the remaining portions. (Exposing the existing logging interface, and noting the change to make krb-diag work on the S7000.) With that in mind, +1. Note however that my +1 specifically excludes the various enhancements to mdb and dtrace (other than the principle that having such would be good), until either they are specified by additional case work or details are included here. - Garrett From Nicolas.Williams@oracle.com Tue Apr 20 09:14:08 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3KGE87g022359 for ; Tue, 20 Apr 2010 09:14:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3KGE49G008854; Tue, 20 Apr 2010 09:14:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1600I17NRITV00@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Apr 2010 09:14:06 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1600D5NNRHSIE0@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Apr 2010 09:14:05 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3KGDxAf002994; Tue, 20 Apr 2010 16:13:59 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3K3P6rF013774; Tue, 20 Apr 2010 16:13:56 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 174707351271779933; Tue, 20 Apr 2010 09:12:13 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Apr 2010 09:12:12 -0700 Date: Tue, 20 Apr 2010 11:12:05 -0500 From: Nicolas Williams Subject: Re: Kerberos Diagnostic Enhancements (umbrella case) [PSARC/2010/135 FastTrack timeout 04/27/2010] In-reply-to: <1271777220.4577.2.camel@phalan> To: Mark Phalan Cc: "Garrett D'Amore" , Wyllys Ingersoll , PSARC-ext@sun.com, shawn.emery@oracle.com Message-id: <20100420161204.GM10389@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BCDD2C6.01D0:SCFMA4539814,ss=1,fgs=0 References: <201004201402.o3KE2uTQ009770@borg.sfbay> <4BCDC4EE.9020908@oracle.com> <1271777220.4577.2.camel@phalan> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1466 On Tue, Apr 20, 2010 at 05:27:00PM +0200, Mark Phalan wrote: > On Tue, 2010-04-20 at 08:14 -0700, Garrett D'Amore wrote: > > This all looks pretty good. I'd like to see an actual list of the mdb > > macros and DTrace probes that have been proposed. > > Expect more cases exposing the Dtrace probes (soon) and MDB macros > (later). It is an _umbrella_ case, after all :) > > 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 > > ... > > I think that this concern can be followed up in the cases which will > introduce the probes and macros. The DTrace probe case I've reviewed very much allows for recovery of plaintexts and keys that otherwise would be impossible with snoop (but not impossible with wireshark, if you give it the keys it needs to decrypt things). That's part of the point. And, in fact, one can very much get at such cleartext and keys _now_ using DTrace, as I've blogged about in the past -- it's just that using the PID provider to do so is painful, while a properly designed USDT provider will make it much easier. I therefore reject Garret's concern -- it is not architectural, to start, and nothing in this case or subsequent cases does anything w.r.t. to access to sensitive information that DTrace hadn't already done. Nico --