From Craig.Payne@Sun.COM Fri Jul 23 09:46:32 2004
Date: Fri, 23 Jul 2004 09:47:58 -0700
From: Craig Payne <Craig.Payne@Sun.COM>
Subject: Re: Contract for GDM to use Solaris Audit interfaces.
To: Gary Winiger <gww@marduk.eng.sun.com>
Cc: Leo.Binchy@Sun.COM, Tony.Panero@Sun.COM, Brian.Cameron@Sun.COM
Content-transfer-encoding: 7bit
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414
X-Lines: 178
Status: RO
Content-Type: text/plain; format="flowed"; charset="us-ascii"
Content-Length: 7619

Approved - Craig Payne, Mgr. Security Technology

-- 
Craig Payne
Manager, Security Technologies
Kerberos & Hardening/Integrity
(510) 550-7413 x30176


From leo.binchy@sun.com Thu Jul 29 08:35:28 2004
Date: Thu, 29 Jul 2004 16:36:42 +0100
From: Leontine Binchy <leo.binchy@sun.com>
Subject: Re: Contract for GDM to use Solaris Audit interfaces.
To: Gary Winiger <gww@marduk.eng.sun.com>
Cc: Craig.Payne@Sun.COM, Tony.Panero@Sun.COM, Brian.Cameron@Sun.COM
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040611
X-Lines: 175
Status: RO
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Length: 7332


I accept this contract

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES

0.  Number:	PSARC/2000/517-05

1.  This contract is between
	a SUPPLIER of INTERFACES and
	a CONSUMER of those INTERFACES,
    both of whom are entities within Sun Microsystems, Incorporated.

2.  The SUPPLIER (definer and/or implementor) is identified by the following:
    Product or Bundle:		Solaris Audit
    Consolidation:		ON
    Department or Group:	Solaris Security
    Bugtraq Category/SubCategory: c2_bsm/other
    Responsible Manager:	Craig Payne

3.  The CONSUMER is identified by the following:
    Product or Bundle:		GNOME
    Consolidation:		GNOME
    Department or Group:	Desktop Development
    Bugtraq Category/SubCategory: gnome/login
    Responsible Manager:	Leontine Binchy

4.  The INTERFACES are:
    A. The Project Private header files <bsm/adt.h> and <bsm/adt_event.h>
    B. The Project Private adt.h interfaces and symbols:
	adt_start_session(, NULL,
	    [ADT_USE_PROC_DATA for all successful login | 0 for fail login,
	    and successful and failed password change]);
	adt_end_session();
	adt_set_user(, [authenticated userid, groupid, userid, groupid,
	    NULL, ADT_USER for successful login and password change |
	    ADT_NO_ATTRIB, ADT_NO_ATTRIB, ADT_NO_ATTRIB, ADT_NO_ATTRIB,
	    <terminal id from adt_load_hostname()>, ADT_NEW for failed login]);
	adt_set_user(, ADT_NO_ATTRIB, ADT_NO_ATTRIB, ADT_NO_ATTRIB,
	    ADT_NO_ATTRIB, NULL, ADT_NEW);
	and
	adt_set_proc(); to reset the process audit state when the process
		is reused.
	adt_alloc_event();
	adt_free_event();
	adt_load_hostname([NULL for failed login from local host |
		remote hostname for failed login from remote host]);
	adt_put_event(, [ADT_SUCCESS for success | ADT_FAILURE for error],
	    [ADT_SUCCESS for success | ADT_FAIL_PAM + pam_error_value]);
    C. The Project Private adt_event.h audit events and symbols:
	ADT_login and adt_login_t (no values for the members)
	ADT_logout and adt_logout_t (no values for the members)
	ADT_passwd and adt_passwd_t (no values for the members)

5.  The ARC controlling these INTERFACES is: PSARC

6.  The CASE describing these INTERFACES is: 2000/517 and 2003/397

7.  The following SPECIAL ARRANGEMENTS are made which modify the rules
    imposed by the stability levels listed in section 4 above:
 
_N_ 7a. Although the stability level doesn't normally restrict it,
        SUPPLIER promises to only modify INTERFACES in an incompatible
	way as follows:

_Y_ 7b. Although the stability level doesn't normally allow it, CONSUMER will
        expose INTERFACES to a PARTNER, which is external to Sun, namely:
		The GNOME Open Source Community.  The Sun Desktop GNOME
		team will act as the interface between Sun and the
		GNOME Open Source Community.

_Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will
        import INTERFACES from a separate consolidation.

_N_ 7d. If SUPPLIER decides to change (including replace or remove) any
	portion of the INTERFACES, SUPPLIER will notify CONSUMER of the
	proposed new version, no later than the application for ARC
	approval of the new version.
	If SUPPLIER and CONSUMER are contained in the same consolidation,
	they have the option of arranging for simultaneous conversion
	to the new interfaces.  If this is not possible, or if they are
	not in the same consolidation, then SUPPLIER will either make best
	effort to work with CONSUMER so that CONSUMER can detect which
	version of INTERFACES is being supplied, or else SUPPLIER will
	make best effort to supply both old and new versions of
	INTERFACES.
	If SUPPLIER cannot make both versions of INTERFACES available,
	and SUPPLIER and CONSUMER cannot devise a method whereby
	CONSUMER can detect which version of INTERFACES is being
	supplied, and the old version of CONSUMER will not run with the
	new version of SUPPLIER, then either the EOL process must be
	followed by SUPPLIER, or else a major release of SUPPLIER will
	be required, or the change will not be allowed.

8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make
   best effort to accommodate such changes, which shall then be
   treated in accordance with paragraph 7 above.

9. Notwithstanding paragraphs 7 and 8, a change to any portion
   of the INTERFACES shall be regarded as a completely new set of
   INTERFACES which require both ARC approval and execution of
   a new contract.

10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
    handled as follows:

    SUPPLIER will notify CONSUMER of changes that may affect the CONSUMER
    not less than two ON consolidation builds before the changes are
    integrated.
    CONSUMER may request changes to the INTERFACES by filing RFEs using
    the Bugtraq Category/SubCategory specified in paragraph 2.  The SUPPLIER
    will review the CONSUMER's RFEs based on their priority and severity and
    either accept them in the normal queue of work or notify the CONSUMER
    through the normal Bugtraq process that the request has been rejected
    and rationale for the rejection.

11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
    follows:

    The CONSUMER may submit bugs against the interfaces using the Bugtraq
    Category/SubCategory specified in paragraph 2.  The SUPPLIER will fix
    bugs based on their priority and severity.

12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
    follows:

    In the supplied <bsm/adt.h> and <bsm/adt_event.h> header files and
    in the case directory
    /net/sac.eng/export/sac/PSARC/2000/517/final.materials/*3BSM

13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
    tested as follows:

    The SUPPLIER will do initial unit testing.  The CONSUMER will create
    an audit trail or trails with each of the audit events generated.
    The SUPPLIER will verify the audit records are correctly generated.

14. SUPPLIER and CONSUMER agree that this contract can be terminated as
    follows:

    By agreement of both parties.

15. This contract is not valid until "signed" via agreement from the
    SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
    this contract.  E-mail agreement to the contract should be archived
    in the mail archive of CASE; verbal agreement to the contract
    should be noted in the meeting minutes.  This contract remains
    valid until superseded or invalidated.

For SUPPLIER:	Craig Payne	Date: 23 July, 2004
For CONSUMER:	Leontine Binchy	Date: 29 July, 2004
For ARC:	Gary Winiger	Date: 29 July, 2004

    A copy of this contract shall be deposited in the CASE directory as
    "contract-05".

16. (Not to be filled in until superseded or invalidated.)
    This contract was superseded or invalidated by CASE:
    For ARC:			Date:
