From sacadmin Mon Oct 6 15:20:12 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m96MKC5u013566; Mon, 6 Oct 2008 15:20:12 -0700 (PDT) Received: (from mk200726@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m96MKC42013562; Mon, 6 Oct 2008 15:20:12 -0700 (PDT) Date: Mon, 6 Oct 2008 15:20:12 -0700 (PDT) From: Michael Kearney Message-Id: <200810062220.m96MKC42013562@sac.sfbay.sun.com> To: LSARC@sac.sfbay.sun.com Cc: Vanessa.Black@Sun.COM Subject: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008] Status: RO Content-Length: 7180 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iSNS GUI: Browser UI for Internet Storage Name Service Server 1.2. Name of Document Author/Supplier: Vanessa Black 1.3. Date of This Document: 10/06/08 2. Project Summary 2.1. Project Description: This project represents a browser user interface supporting management operations for the Solaris iSNS server - an alternative to the CLI for iSNS server management. Through this graphical user interface, a user will be able to create configurations involving hundreds of nodes with the ease not attainable through the CLI. The visualization of the isns_server system, as well as the task-based wizards that walk the user through management operations provide functionality needed for the administrator working with a larger-than-small-scale configuration. Intended type of release for this project: Patch binding Projects this project is part of: iSNS Server PSARC/2006/319 Projects that depend on or interoperate with this project: None 4. Technical Description: 4.1. Details: The architecture consists of a web application making requests to a JMX-based proxy server which exposes a JNI interface to the Isns Server's C API. The GUI will deploy to the Lockhart console and will use web components as provided by the Braveheart release (JSF-based). The web application makes an RMI connection to the proxy server - the Common Agent Container aka cacao. A single Managed Bean is registered by this project into the container. The MBean exposes the JNI interface which makes requests to the doors server and the C Isns Server API. Use of this proxy server makes it possible for a web container to make requests in Java of the C-based Isns server , on behalf of its authenticated and authorized user. Block diagram: +-------------------------+ | Browser | +-------------------------+ | | HTTP (Security: PAM) | V +-------------------------+ | Webserver | +-------------------------+ | | JMX/RMI (Security:PAM) | V +-------------------------+ | Proxy Server | + + | JNI | +-------------------------+ | | Doors Interface | V +-------------------------+ | iSNS Server | +-------------------------+ 4.5. Interfaces: _______________________________________________________________________ | Interfaces Exported | |_________________________|_________________|__________________________| |Interface | Classification | Comments | |_________________________|_________________|__________________________| |URL for Lockhart | Committed | https://:6789 | | | | LSARC 2008/020 | |_________________________|_________________|__________________________| |Browser-based GUI | Uncommitted | | |_________________________|_________________|__________________________| | ISNS MBean | project private| | |(JMX Managed Bean) | | | |_________________________|_________________|__________________________| __________________________________________________________________ | Interfaces Imported | |____________________________|_________________|_________________| |Interface | Classification | Comments | |____________________________|_________________|_________________| |isns_server_Door | project private | imported from | | | | iSNS Server | | | | PSARC/2006/319 | |____________________________|_________________|_________________| |Common Agent Container | Public stable | LSARC/2005/339 | | 2.0 | | | |____________________________|_________________|_________________| |Lockhart authorization | Committed | LSARC/2008/020 | |class: | | | |AuthorizationServiceFactory | | | |____________________________|_________________|_________________| 4.10. Packaging & Delivery: Installation of the package will lay the web application files out in exploded war fashion so that it can be consumed by the Lockhart console's deployment operation. The files for the Isns MBean will be laid in a location following Solaris 11 packaging rules and post install scripts will run to deploy it into the Common Agent Container. Any jars that we bundle will be overridden by jars existing on the installed system. 4.11. Security Impact: - Authentication/authorization into the web application is provided by the console's infrastructure which uses PAM (see http://sac.eng/Archives/CaseLog/arc/LSARC/2008/020/) - The web application uses the Lockhart authorization classes (above) to tell whether a user is authorized to see privileged pages or not. - Connection from the web application to the JMX proxy server is requested as an “Unknown Client Connection” and so the user's credentials are passed in. - Access to Isns write operations exposed by the Isns MBean are configured for protected by Common Agent Container security infrastructure. This uses PAM to check the user for RBAC privileges to invoke these write operations. So, whether these operations are invoked by the Isns BUI or some other authenticated client, only users with the RBAC authorization will be able to invoke the privileged operations. UIRB Approval Reference: 2006/674 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Tue Oct 7 07:40:28 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m97EeStg015799; Tue, 7 Oct 2008 07:40:28 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m97EeROv011650; Tue, 7 Oct 2008 07:40:27 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m97EeR0h000077; Tue, 7 Oct 2008 14:40:27 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8D00901I0SFR00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM); Tue, 07 Oct 2008 08:40:27 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8D00MKHI3D5VD0@mail-amer.sun.com>; Tue, 07 Oct 2008 08:40:26 -0600 (MDT) Date: Tue, 07 Oct 2008 07:40:25 -0700 From: John Fischer Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008] In-reply-to: <200810062220.m96MKC42013562@sac.sfbay.sun.com> Sender: John.Fischer@Sun.COM To: Michael Kearney Cc: LSARC@sac.sfbay.sun.com, Vanessa.Black@Sun.COM Reply-to: John.Fischer@Sun.COM Message-id: <1223390425.50059.3212.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT References: <200810062220.m96MKC42013562@sac.sfbay.sun.com> Status: RO Content-Length: 7538 +1 On Mon, 2008-10-06 at 15:20, Michael Kearney wrote: > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > iSNS GUI: Browser UI for Internet Storage Name Service Server > > 1.2. Name of Document Author/Supplier: Vanessa Black > > 1.3. Date of This Document: 10/06/08 > > 2. Project Summary > 2.1. Project Description: > This project represents a browser user interface supporting management operations for the Solaris iSNS server - an alternative to the CLI for iSNS server management. Through this graphical user interface, a user will be able to create configurations involving hundreds of nodes with the ease not attainable through the CLI. The visualization of the isns_server system, as well as the task-based wizards that walk the user through management operations provide functionality needed for the administrator working with a larger-than-small-scale configuration. > > Intended type of release for this project: > > Patch binding > > > Projects this project is part of: > > iSNS Server PSARC/2006/319 > > > Projects that depend on or interoperate with this project: > > None > > > 4. Technical Description: > 4.1. Details: > > The architecture consists of a web application making requests to a JMX-based proxy server which exposes a JNI interface to the Isns Server's C API. > > The GUI will deploy to the Lockhart console and will use web components as provided by the Braveheart release (JSF-based). > > The web application makes an RMI connection to the proxy server - the Common Agent Container aka cacao. A single Managed Bean is registered by this project into the container. The MBean exposes the JNI interface which makes requests to the doors server and the C Isns Server API. > > Use of this proxy server makes it possible for a web container to make requests in Java of the C-based Isns server , on behalf of its authenticated and authorized user. > > > > > Block diagram: > > +-------------------------+ > | Browser | > +-------------------------+ > | > | > HTTP (Security: PAM) > | > V > +-------------------------+ > | Webserver | > +-------------------------+ > | > | > JMX/RMI (Security:PAM) > | > V > +-------------------------+ > | Proxy Server | > + + > | JNI | > +-------------------------+ > | > | > Doors Interface > | > V > +-------------------------+ > | iSNS Server | > +-------------------------+ > > > > > > > > > 4.5. Interfaces: > _______________________________________________________________________ > | Interfaces Exported | > |_________________________|_________________|__________________________| > |Interface | Classification | Comments | > |_________________________|_________________|__________________________| > |URL for Lockhart | Committed | https://:6789 | > | | | LSARC 2008/020 | > |_________________________|_________________|__________________________| > |Browser-based GUI | Uncommitted | | > |_________________________|_________________|__________________________| > | ISNS MBean | project private| | > |(JMX Managed Bean) | | | > |_________________________|_________________|__________________________| > > > __________________________________________________________________ > | Interfaces Imported | > |____________________________|_________________|_________________| > |Interface | Classification | Comments | > |____________________________|_________________|_________________| > |isns_server_Door | project private | imported from | > | | | iSNS Server | > | | | PSARC/2006/319 | > |____________________________|_________________|_________________| > |Common Agent Container | Public stable | LSARC/2005/339 | > | 2.0 | | | > |____________________________|_________________|_________________| > |Lockhart authorization | Committed | LSARC/2008/020 | > |class: | | | > |AuthorizationServiceFactory | | | > |____________________________|_________________|_________________| > > > > 4.10. Packaging & Delivery: > Installation of the package will lay the web application files out in exploded war fashion so that it can be consumed by the Lockhart console's deployment operation. The files for the Isns MBean will be laid in a location following Solaris 11 packaging rules and post install scripts will run to deploy it into the Common Agent Container. Any jars that we bundle will be overridden by jars existing on the installed system. > > > 4.11. Security Impact: > > - Authentication/authorization into the web application is provided by the console's infrastructure which uses PAM (see http://sac.eng/Archives/CaseLog/arc/LSARC/2008/020/) > > - The web application uses the Lockhart authorization classes (above) to tell whether a user is authorized to see privileged pages or not. > > - Connection from the web application to the JMX proxy server is requested as an ?Unknown Client Connection? and so the user's credentials are passed in. > > - Access to Isns write operations exposed by the Isns MBean are configured for protected by Common Agent Container security infrastructure. This uses PAM to check the user for RBAC privileges to invoke these write operations. So, whether these operations are invoked by the Isns BUI or some other authenticated client, only users with the RBAC authorization will be able to invoke the privileged operations. > > > > > UIRB Approval Reference: > 2006/674 > > > > > > > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > sfw > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From sacadmin Tue Oct 7 08:06:38 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m97F6cNo017269; Tue, 7 Oct 2008 08:06:38 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m97F6bv3015991; Tue, 7 Oct 2008 08:06:37 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m97F6bmj011236; Tue, 7 Oct 2008 15:06:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8D00601I3FV200@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Tue, 07 Oct 2008 09:06:37 -0600 (MDT) Received: from Macintosh-205.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8D003RWJAR6WA0@mail-amer.sun.com>; Tue, 07 Oct 2008 09:06:28 -0600 (MDT) Date: Tue, 07 Oct 2008 09:06:27 -0600 From: "Mark A. Carlson" Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008] In-reply-to: <1223390425.50059.3212.camel@sr1-umpk-16> Sender: Mark.Carlson@Sun.COM To: Michael Kearney Cc: LSARC@sac.sfbay.sun.com, Vanessa.Black@Sun.COM Message-id: <48EB7AF3.2020307@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mI7wLVe3Fv+y7o+0h7Tr7g)" References: <200810062220.m96MKC42013562@sac.sfbay.sun.com> <1223390425.50059.3212.camel@sr1-umpk-16> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 15920 This is a multi-part message in MIME format. --Boundary_(ID_mI7wLVe3Fv+y7o+0h7Tr7g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Ditto. +1 -- mark John Fischer wrote: > +1 > > On Mon, 2008-10-06 at 15:20, Michael Kearney wrote: > >> Template Version: @(#)sac_nextcase %I% %G% SMI >> This information is Copyright 2008 Sun Microsystems >> >> 1. Introduction >> 1.1. Project/Component Working Name: >> iSNS GUI: Browser UI for Internet Storage Name Service Server >> >> 1.2. Name of Document Author/Supplier: Vanessa Black >> >> 1.3. Date of This Document: 10/06/08 >> >> 2. Project Summary >> 2.1. Project Description: >> This project represents a browser user interface supporting management operations for the Solaris iSNS server - an alternative to the CLI for iSNS server management. Through this graphical user interface, a user will be able to create configurations involving hundreds of nodes with the ease not attainable through the CLI. The visualization of the isns_server system, as well as the task-based wizards that walk the user through management operations provide functionality needed for the administrator working with a larger-than-small-scale configuration. >> >> Intended type of release for this project: >> >> Patch binding >> >> >> Projects this project is part of: >> >> iSNS Server PSARC/2006/319 >> >> >> Projects that depend on or interoperate with this project: >> >> None >> >> >> 4. Technical Description: >> 4.1. Details: >> >> The architecture consists of a web application making requests to a JMX-based proxy server which exposes a JNI interface to the Isns Server's C API. >> >> The GUI will deploy to the Lockhart console and will use web components as provided by the Braveheart release (JSF-based). >> >> The web application makes an RMI connection to the proxy server - the Common Agent Container aka cacao. A single Managed Bean is registered by this project into the container. The MBean exposes the JNI interface which makes requests to the doors server and the C Isns Server API. >> >> Use of this proxy server makes it possible for a web container to make requests in Java of the C-based Isns server , on behalf of its authenticated and authorized user. >> >> >> >> >> Block diagram: >> >> +-------------------------+ >> | Browser | >> +-------------------------+ >> | >> | >> HTTP (Security: PAM) >> | >> V >> +-------------------------+ >> | Webserver | >> +-------------------------+ >> | >> | >> JMX/RMI (Security:PAM) >> | >> V >> +-------------------------+ >> | Proxy Server | >> + + >> | JNI | >> +-------------------------+ >> | >> | >> Doors Interface >> | >> V >> +-------------------------+ >> | iSNS Server | >> +-------------------------+ >> >> >> >> >> >> >> >> >> 4.5. Interfaces: >> _______________________________________________________________________ >> | Interfaces Exported | >> |_________________________|_________________|__________________________| >> |Interface | Classification | Comments | >> |_________________________|_________________|__________________________| >> |URL for Lockhart | Committed | https://:6789 | >> | | | LSARC 2008/020 | >> |_________________________|_________________|__________________________| >> |Browser-based GUI | Uncommitted | | >> |_________________________|_________________|__________________________| >> | ISNS MBean | project private| | >> |(JMX Managed Bean) | | | >> |_________________________|_________________|__________________________| >> >> >> __________________________________________________________________ >> | Interfaces Imported | >> |____________________________|_________________|_________________| >> |Interface | Classification | Comments | >> |____________________________|_________________|_________________| >> |isns_server_Door | project private | imported from | >> | | | iSNS Server | >> | | | PSARC/2006/319 | >> |____________________________|_________________|_________________| >> |Common Agent Container | Public stable | LSARC/2005/339 | >> | 2.0 | | | >> |____________________________|_________________|_________________| >> |Lockhart authorization | Committed | LSARC/2008/020 | >> |class: | | | >> |AuthorizationServiceFactory | | | >> |____________________________|_________________|_________________| >> >> >> >> 4.10. Packaging & Delivery: >> Installation of the package will lay the web application files out in exploded war fashion so that it can be consumed by the Lockhart console's deployment operation. The files for the Isns MBean will be laid in a location following Solaris 11 packaging rules and post install scripts will run to deploy it into the Common Agent Container. Any jars that we bundle will be overridden by jars existing on the installed system. >> >> >> 4.11. Security Impact: >> >> - Authentication/authorization into the web application is provided by the console's infrastructure which uses PAM (see http://sac.eng/Archives/CaseLog/arc/LSARC/2008/020/) >> >> - The web application uses the Lockhart authorization classes (above) to tell whether a user is authorized to see privileged pages or not. >> >> - Connection from the web application to the JMX proxy server is requested as an ?Unknown Client Connection? and so the user's credentials are passed in. >> >> - Access to Isns write operations exposed by the Isns MBean are configured for protected by Common Agent Container security infrastructure. This uses PAM to check the user for RBAC privileges to invoke these write operations. So, whether these operations are invoked by the Isns BUI or some other authenticated client, only users with the RBAC authorization will be able to invoke the privileged operations. >> >> >> >> >> UIRB Approval Reference: >> 2006/674 >> >> >> >> >> >> >> >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> sfw >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> > > --Boundary_(ID_mI7wLVe3Fv+y7o+0h7Tr7g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Ditto. +1

-- mark

John Fischer wrote: 
+1

On Mon, 2008-10-06 at 15:20, Michael Kearney wrote:
  
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems

1. Introduction
   1.1. Project/Component Working Name:
   iSNS GUI: Browser UI for Internet Storage Name Service Server 

   1.2. Name of Document Author/Supplier: Vanessa Black

   1.3. Date of This Document: 10/06/08

2. Project Summary
  2.1. Project Description:
This project represents a browser user interface supporting management operations for the Solaris iSNS server - an alternative to the CLI for iSNS server management. Through this graphical user interface, a user will be able to create configurations involving hundreds of nodes with the ease not attainable through the CLI. The visualization of the isns_server system, as well as the task-based wizards that walk the user through management operations provide functionality needed for the administrator working with a larger-than-small-scale configuration.

Intended type of release for this project:

Patch binding


Projects this project is part of:

iSNS Server PSARC/2006/319


Projects that depend on or interoperate with this project:

None


4. Technical Description:
    4.1. Details:

The architecture consists of a web application making requests to a JMX-based proxy server which exposes a JNI interface to the Isns Server's C API.

The GUI will deploy to the Lockhart console and will use web components as provided by the Braveheart release (JSF-based). 

The web application makes an RMI connection to the proxy server - the Common Agent Container aka cacao. A single Managed Bean is registered by this project into the container. The MBean exposes the JNI interface which makes requests to the doors server and the C Isns Server API. 

Use of this proxy server makes it possible for a web container to make requests in Java of the C-based Isns server , on behalf of its authenticated and authorized user.




Block diagram:

             +-------------------------+                               
             |        Browser          |                                                  
             +-------------------------+ 
                         |               
                         |                                       
                       HTTP  (Security: PAM)
                         |               
                        V                
             +-------------------------+                               
             |       Webserver         |                                                 
             +-------------------------+ 
                         |               
                         |                                       
                      JMX/RMI (Security:PAM)
                         |               
                        V          
             +-------------------------+                              
             |      Proxy Server       |                                                   
             +                         +              
             |          JNI            |                                       
             +-------------------------+     
                         |
                         |
                  Doors Interface    
                         |
                        V                                    
             +-------------------------+                              
             |       iSNS Server       |                                                  
             +-------------------------+                








    4.5. Interfaces:
_______________________________________________________________________
|                     Interfaces Exported                              |
|_________________________|_________________|__________________________|
|Interface                |  Classification |  Comments                |
|_________________________|_________________|__________________________|
|URL for Lockhart         |   Committed     | https://<hostname>:6789  |
|                         |                 | LSARC 2008/020           |
|_________________________|_________________|__________________________|
|Browser-based GUI        |  Uncommitted    |                          |
|_________________________|_________________|__________________________|
| ISNS MBean              |  project private|                          |
|(JMX Managed Bean)       |                 |                          |
|_________________________|_________________|__________________________|


__________________________________________________________________
|                     Interfaces Imported                        |
|____________________________|_________________|_________________|
|Interface                   |  Classification |  Comments       |
|____________________________|_________________|_________________|
|isns_server_Door            | project private | imported from   |
|                            |                 | iSNS Server     |
|                            |                 |  PSARC/2006/319 |
|____________________________|_________________|_________________|  
|Common Agent Container      | Public stable   | LSARC/2005/339  |
| 2.0                        |                 |                 |
|____________________________|_________________|_________________|
|Lockhart authorization      | Committed       | LSARC/2008/020  |
|class:                      |                 |                 |
|AuthorizationServiceFactory |                 |                 | 
|____________________________|_________________|_________________| 



4.10. Packaging & Delivery:
Installation of the package will lay the web application files out in exploded war fashion so that it can be consumed by the Lockhart console's deployment operation. The files for the Isns MBean will be laid in a location following Solaris 11 packaging rules and post install scripts will run to deploy it into the Common Agent Container. Any jars that we bundle will be overridden by jars existing on the installed system.


4.11. Security Impact:

- Authentication/authorization into the web application is provided by the console's infrastructure which uses PAM (see http://sac.eng/Archives/CaseLog/arc/LSARC/2008/020/)

- The web application uses the Lockhart authorization classes (above) to tell whether a user is authorized to see privileged pages or not.

- Connection from the web application to the JMX proxy server is requested as an ?Unknown Client Connection? and so the user's credentials are passed in.

- Access to Isns write operations exposed by the Isns MBean are configured for protected by Common Agent Container security infrastructure. This uses PAM to check the user for RBAC privileges to invoke these write operations. So, whether these operations are invoked by the Isns BUI or some other authenticated client, only users with the RBAC authorization will be able to invoke the privileged operations.




UIRB Approval Reference: 
2006/674









6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		sfw
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open
--Boundary_(ID_mI7wLVe3Fv+y7o+0h7Tr7g)-- From sacadmin Tue Oct 7 08:21:11 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02.SFBay.Sun.COM [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m97FLBu2019505; Tue, 7 Oct 2008 08:21:11 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m97FLAYS039413; Tue, 7 Oct 2008 08:21:10 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m97FM6q3009969; Tue, 7 Oct 2008 08:22:06 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m97FM6oh009968; Tue, 7 Oct 2008 08:22:06 -0700 (PDT) Date: Tue, 7 Oct 2008 08:22:06 -0700 (PDT) From: Gary Winiger Message-Id: <200810071522.m97FM6oh009968@marduk.eng.sun.com> To: LSARC@sac.sfbay.sun.com, mk200726@sac.sfbay.sun.com Cc: Vanessa.Black@sun.com Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008] Status: RO Content-Length: 3874 > 4. Technical Description: > 4.1. Details: > The architecture consists of a web application making requests to a JMX-based proxy server which exposes a JNI interface to the Isns Server's C API. > > The GUI will deploy to the Lockhart console and will use web components as provided by the Braveheart release (JSF-based). > 4.5. Interfaces: > _______________________________________________________________________ > | Interfaces Exported | > |_________________________|_________________|__________________________| > |Interface | Classification | Comments | > |_________________________|_________________|__________________________| > |URL for Lockhart | Committed | https://:6789 | > | | | LSARC 2008/020 | > |_________________________|_________________|__________________________| > |Browser-based GUI | Uncommitted | | > |_________________________|_________________|__________________________| > | ISNS MBean | project private| | > |(JMX Managed Bean) | | | > |_________________________|_________________|__________________________| > > __________________________________________________________________ > | Interfaces Imported | > |____________________________|_________________|_________________| > |Interface | Classification | Comments | > |____________________________|_________________|_________________| > |isns_server_Door | project private | imported from | > | | | iSNS Server | > | | | PSARC/2006/319 | > |____________________________|_________________|_________________| > |Common Agent Container | Public stable | LSARC/2005/339 | > | 2.0 | | | > |____________________________|_________________|_________________| > |Lockhart authorization | Committed | LSARC/2008/020 | > |class: | | | > |AuthorizationServiceFactory | | | > |____________________________|_________________|_________________| > > 4.11. Security Impact: > > - Authentication/authorization into the web application is provided by the console's infrastructure which uses PAM (see http://sac.eng/Archives/CaseLog/arc/LSARC/2008/020/) > > - The web application uses the Lockhart authorization classes (above) to tell whether a user is authorized to see privileged pages or not. > > - Connection from the web application to the JMX proxy server is requested as an “Unknown Client Connection” and so the user's credentials are passed in. > > - Access to Isns write operations exposed by the Isns MBean are configured > for protected by Common Agent Container security infrastructure. This uses > PAM to check the user for RBAC privileges to invoke these write operations. PAM does no checks for "RBAC privileges" -- I'm confused by this term -- Solaris has privileges see PSARC/2002/188. RBAC associates privileges with executable programs via pfexec(1M). > So, whether these operations are invoked by the Isns BUI or some other > authenticated client, only users with the RBAC authorization will be able to > invoke the privileged operations. RBAC does have authorizations which are enforced by privileged programs through the chkauthattr(3secdb) interface. I'm confused about the security impact as stated. Additionally I don't see how this project meets the Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ Gary.. From sacadmin Tue Oct 7 11:42:45 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m97IgiAe008527; Tue, 7 Oct 2008 11:42:44 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m97Igi0m052450; Tue, 7 Oct 2008 11:42:44 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m97IgiGJ011755; Tue, 7 Oct 2008 18:42:44 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8D00L01SG1NS00@mail-amer.sun.com> (original mail from Vanessa.Black@Sun.COM); Tue, 07 Oct 2008 12:42:44 -0600 (MDT) Received: from [172.20.26.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8D007OATB39820@mail-amer.sun.com>; Tue, 07 Oct 2008 12:42:39 -0600 (MDT) Date: Tue, 07 Oct 2008 12:42:39 -0600 From: Vanessa Black Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008] In-reply-to: <200810071522.m97FM6oh009968@marduk.eng.sun.com> Sender: Vanessa.Black@Sun.COM To: Gary Winiger Cc: LSARC@sac.sfbay.sun.com, mk200726@sac.sfbay.sun.com Reply-to: Vanessa.Black@Sun.COM Message-id: <48EBAD9F.40201@Sun.COM> MIME-version: 1.0 Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810071522.m97FM6oh009968@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 6677

Gary Winiger wrote: 
4. Technical Description:
    4.1. Details:
    

  
The architecture consists of a web application making requests to a JMX-based proxy server which exposes a JNI interface to the Isns Server's C API.

The GUI will deploy to the Lockhart console and will use web components as provided by the Braveheart release (JSF-based). 
    

  
    4.5. Interfaces:
_______________________________________________________________________
|                     Interfaces Exported                              |
|_________________________|_________________|__________________________|
|Interface                |  Classification |  Comments                |
|_________________________|_________________|__________________________|
|URL for Lockhart         |   Committed     | https://<hostname>:6789  |
|                         |                 | LSARC 2008/020           |
|_________________________|_________________|__________________________|
|Browser-based GUI        |  Uncommitted    |                          |
|_________________________|_________________|__________________________|
| ISNS MBean              |  project private|                          |
|(JMX Managed Bean)       |                 |                          |
|_________________________|_________________|__________________________|

__________________________________________________________________
|                     Interfaces Imported                        |
|____________________________|_________________|_________________|
|Interface                   |  Classification |  Comments       |
|____________________________|_________________|_________________|
|isns_server_Door            | project private | imported from   |
|                            |                 | iSNS Server     |
|                            |                 |  PSARC/2006/319 |
|____________________________|_________________|_________________|  
|Common Agent Container      | Public stable   | LSARC/2005/339  |
| 2.0                        |                 |                 |
|____________________________|_________________|_________________|
|Lockhart authorization      | Committed       | LSARC/2008/020  |
|class:                      |                 |                 |
|AuthorizationServiceFactory |                 |                 | 
|____________________________|_________________|_________________| 

4.11. Security Impact:

- Authentication/authorization into the web application is provided by the console's infrastructure which uses PAM (see http://sac.eng/Archives/CaseLog/arc/LSARC/2008/020/)

- The web application uses the Lockhart authorization classes (above) to tell whether a user is authorized to see privileged pages or not.

- Connection from the web application to the JMX proxy server is requested as an “Unknown Client Connection” and so the user's credentials are passed in.

- Access to Isns write operations exposed by the Isns MBean are configured
for protected by Common Agent Container security infrastructure. This uses
PAM to check the user for RBAC privileges to invoke these write operations.
    

	PAM does no checks for "RBAC privileges"  -- I'm confused by this
	term -- Solaris has privileges see PSARC/2002/188.  RBAC associates
	privileges with executable programs via pfexec(1M).
-Authentication/authorization into the JMX tier is provided by the Common Agent Container - see LSARC/2005/339.

To state the use of RBAC and PAM  accurately:
-Access to Isns write operations exposed by the Isns MBean are configured for protected by Common Agent Container security infrastructure. This uses PAM to validate the username and password against the system's configuration databases. The Isns MBean then makes use of the Common Agent Container's access control framework that verifies the fine-grained access control rights. RBAC access control metadata is stored in a properties file in the mBean. The authenticated user must have the RBAC authorization attribute listed in the properties file in order to have access to the write operations. All of this is handled by the Common Agent Container LSARC/2005/339.



  

    
So, whether these operations are invoked by the Isns BUI or some other
authenticated client, only users with the RBAC authorization will be able to
invoke the privileged operations.
    

  

  

	RBAC does have authorizations which are enforced by privileged
	programs through the chkauthattr(3secdb) interface.

	I'm confused about the security impact as stated.  Additionally
	I don't see how this project meets the Audit Policy
	http://opensolaris.org/os/community/arc/policies/audit-policy/
  



Since we use  the Lockhart Console LSARC/2008/020 in the web tier and
the Common Agent Container LSARC/2005/339 in the JMX tier for
authentication/authorization, see these cases for Audit Policy.



I believe this should give you the needed clarification.

Vanessa



  
Gary..
  






-- 

Vanessa L. Black 

Storage Platform Software Group

Sun Microsystems Inc.

Broomfield , Colorado


x72984, 303-272-2984





From sacadmin Wed Oct  8 11:24:24 2008
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m98IOOqv023475;
	Wed, 8 Oct 2008 11:24:24 -0700 (PDT)
Received: (from gww@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m98IOOa9023474;
	Wed, 8 Oct 2008 11:24:24 -0700 (PDT)
Date: Wed, 8 Oct 2008 11:24:24 -0700 (PDT)
From: Gary Winiger 
Message-Id: <200810081824.m98IOOa9023474@sac.sfbay.sun.com>
To: Vanessa.Black@Sun.COM, gww@eng.sun.com
Cc: LSARC@sac.sfbay.sun.com, mk200726@sac.sfbay.sun.com
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
Status: RO
Content-Length: 4558

Vanessa> Gary Winiger wrote:

Vanessa>   

Vanessa> 	PAM does no checks for "RBAC privileges"  -- I'm confused by this
Vanessa> 	term -- Solaris has privileges see PSARC/2002/188.  RBAC associates
Vanessa> 	privileges with executable programs via pfexec(1M).
Vanessa> 
Vanessa> 
Vanessa> -Authentication/authorization into the JMX tier is provided by the
Vanessa> Common Agent Container - see LSARC/2005/339. 

Vanessa> 

Vanessa> To state the use of RBAC and PAM  accurately:

Vanessa> -Access to Isns write operations exposed by the Isns MBean are
Vanessa> configured for protected by Common Agent Container security
Vanessa> infrastructure. This uses PAM to validate the username and password
Vanessa> against the system's configuration databases. The Isns MBean then makes
Vanessa> use of the Common Agent Container's access control framework that
Vanessa> verifies the fine-grained access control rights. RBAC access control
Vanessa> metadata is stored in a properties file in the mBean. The authenticated
Vanessa> user must have the RBAC authorization attribute listed in the
Vanessa> properties file in order to have access to the write operations. All of
Vanessa> this is handled by the Common Agent Container LSARC/2005/339.

	
	Excuse my ignorance here:
	So that authorization would be solaris.isnsmgr.write?  And part
	of this project specifies that to common container code?

Vanessa>     
So, whether these operations are invoked by the Isns BUI or some other
Vanessa> authenticated client, only users with the RBAC authorization will be able to
Vanessa> invoke the privileged operations.
Vanessa>   

Vanessa> 	RBAC does have authorizations which are enforced by privileged
Vanessa> 	programs through the chkauthattr(3secdb) interface.
Vanessa> 
Vanessa> 	I'm confused about the security impact as stated.  Additionally
Vanessa> 	I don't see how this project meets the Audit Policy
Vanessa> 	http://opensolaris.org/os/community/arc/policies/audit-policy/
Vanessa> 
Vanessa> Since we use  the Lockhart Console LSARC/2008/020 in the web tier and
Vanessa> the Common Agent Container LSARC/2005/339 in the JMX tier for
Vanessa> authentication/authorization, see these cases for Audit Policy.


	It's know that Cacao does no audit.  Nick and I have been in
	communication about that.  Lockhart does audit login.  In general
	containers may provide functionality, however they don't provide
	sufficient application audit.  Following along with the audit policy,
	you'll note that administrative action (which I presume is taking
	place here) needs to include what was affected.  In the case of
	administrative action, that would be the at minimum the new value
	of what occured.

	What I'd expect a proper audit record to contain is
		what happened -- iSNS configured foo.
			This needs to be supplied by the application
		who did it -- the identified and authenticated system user
				audit context as set by the system login method
				through pam_unix_cred.
		what was affected -- the specific value changed. 
				Passwords and crypto keys are exempt.
				the old value is also desirable.
				Additionally the specific information
				used to enforce the policy that not everyone
				can do this.  Either privileges or
				authorizations that are enforced
				In this case a auth token would be included
				in the audit record specifying the
				solaris.isnsmgr.write authorization was used.
		when it happened -- not something applications have to
				supply if they have a proper audit context
				as in who did it.
		where it happened -- again this is from the proper audit
				context
		was the operation successful or
		did it fail and why it failed -- this needs to be supplied by
				the application.

Vanessa> I believe this should give you the needed clarification.


	Unfortunately not really.  It still sounds to me that this
	project doesn't adequately audit.

	I believe it's useful for this to be on record.

	I leave it to the committee to decide what to do with this information
	relative to the current project.

	The architectural policy is in support of the business requirement
	to evaluate and certify Solaris based on the Common Criteria
	Protection Profiles.
	There are other architectural policies such as Internationalization
	Compliance that fall into the same class of business requirement
	support.

Gary..

From sacadmin Wed Oct  8 14:33:13 2008
Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m98LXDiD001053;
	Wed, 8 Oct 2008 14:33:13 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m98LXDda041653;
	Wed, 8 Oct 2008 14:33:13 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m98LXD1X012166;
	Wed, 8 Oct 2008 21:33:13 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0K8F00J01V3HOF00@mail-amer.sun.com>
 (original mail from Vanessa.Black@Sun.COM); Wed,
 08 Oct 2008 15:33:13 -0600 (MDT)
Received: from [172.20.26.30] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0K8F00GKSVV5S090@mail-amer.sun.com>; Wed,
 08 Oct 2008 15:33:05 -0600 (MDT)
Date: Wed, 08 Oct 2008 15:33:05 -0600
From: Vanessa Black 
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
In-reply-to: <200810081824.m98IOOa9023474@sac.sfbay.sun.com>
Sender: Vanessa.Black@Sun.COM
To: Gary Winiger 
Cc: gww@eng.sun.com, LSARC@sac.sfbay.sun.com, mk200726@sac.sfbay.sun.com
Reply-to: Vanessa.Black@Sun.COM
Message-id: <48ED2711.5020400@Sun.COM>
MIME-version: 1.0
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200810081824.m98IOOa9023474@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 8520




  






Gary Winiger wrote:


  
Vanessa> Gary Winiger wrote:

Vanessa>   <pre wrap=""><!---->
Vanessa> 	PAM does no checks for "RBAC privileges"  -- I'm confused by this
Vanessa> 	term -- Solaris has privileges see PSARC/2002/188.  RBAC associates
Vanessa> 	privileges with executable programs via pfexec(1M).
Vanessa> 
Vanessa> </blockquote>
Vanessa> -Authentication/authorization into the JMX tier is provided by the
Vanessa> Common Agent Container - see LSARC/2005/339. <br>
Vanessa> <br>
Vanessa> To state the use of RBAC and PAM&nbsp; accurately:<br>
Vanessa> -Access to Isns write operations exposed by the Isns MBean are
Vanessa> configured for protected by Common Agent Container security
Vanessa> infrastructure. This uses PAM to validate the username and password
Vanessa> against the system's configuration databases. The Isns MBean then makes
Vanessa> use of the Common Agent Container's access control framework that
Vanessa> verifies the fine-grained access control rights. RBAC access control
Vanessa> metadata is stored in a properties file in the mBean. The authenticated
Vanessa> user must have the RBAC authorization attribute listed in the
Vanessa> properties file in order to have access to the write operations. All of
Vanessa> this is handled by the Common Agent Container LSARC/2005/339.<br>
	
	Excuse my ignorance here:
	So that authorization would be solaris.isnsmgr.write?  And part
	of this project specifies that to common container code?
  





Yes the authorization is solaris.isnsmgr.write. The properties file in
the mBean specifies to the container the operations that require this
RBAC authorization in order to be invoked.



  
Vanessa>     <pre wrap="">So, whether these operations are invoked by the Isns BUI or some other
Vanessa> authenticated client, only users with the RBAC authorization will be able to
Vanessa> invoke the privileged operations.
Vanessa>   <pre wrap=""><!---->
Vanessa> 	RBAC does have authorizations which are enforced by privileged
Vanessa> 	programs through the chkauthattr(3secdb) interface.
Vanessa> 
Vanessa> 	I'm confused about the security impact as stated.  Additionally
Vanessa> 	I don't see how this project meets the Audit Policy
Vanessa> 	<a class="moz-txt-link-freetext" href="http://opensolaris.org/os/community/arc/policies/audit-policy/">http://opensolaris.org/os/community/arc/policies/audit-policy/</a>
Vanessa> </blockquote>
Vanessa> Since we use&nbsp; the Lockhart Console LSARC/2008/020 in the web tier and
Vanessa> the Common Agent Container LSARC/2005/339 in the JMX tier for
Vanessa> authentication/authorization, see these cases for Audit Policy.<br>

	It's know that Cacao does no audit.  Nick and I have been in
	communication about that.  



We agree that the approach should be to have Cacao do the
auditing as they mention in their Princples Of
Operation document on: https://common-agent-container.dev.java.net/



Requests are audited in cacao's audit-cacao.0 log:



ALLOWED: RMI : com.sun.cacao.user^Aroot

Oct 7, 2008 7:04:34 PM "rmi://127.0.0.1:26 com.sun.cacao.user^Aroot" MBS

ALLOWED: invoke :
com.sun.netstorage.mgmt.isns:type=com.sun.netstorage.mgmt.jmx.isns.isnsModule.IsnsMBean
: createDomain

Oct 7, 2008 7:04:34 PM "rmi://127.0.0.1:26 com.sun.cacao.user^Aroot" MBS

ALLOWED: invoke :
com.sun.netstorage.mgmt.isns:type=com.sun.netstorage.mgmt.jmx.isns.isnsModule.IsnsMBean
: addDomainSetMembers





If this is broken or unimplemented, they should fix it, but regardless,
it's not this case.







  
Lockhart does audit login.  In general
	containers may provide functionality, however they don't provide
	sufficient application audit.  Following along with the audit policy,
	you'll note that administrative action (which I presume is taking
	place here) needs to include what was affected.  In the case of
	administrative action, that would be the at minimum the new value
	of what occured.
  





The administrative actions having to do with the access control of the
iSCSI network is

accomplished in the iSNS server. The server is invoked by various
client including the

CLI and this project.



Architecturally the best place to do this auditing would be in the
server so that it covers

administrative actions invoked by any of the clients. 



With
this understood I'll answer to the audit requirements below:





  
	What I'd expect a proper audit record to contain is
		what happened -- iSNS configured foo.
			This needs to be supplied by the application
  



The application in this case is iSNS server not the iSNS GUI.


  
		who did it -- the identified and authenticated system user
				audit context as set by the system login method
				through pam_unix_cred.
  



Cacao currently logs in its audit logs who is accessing the client
mBean and what operations were invoked


  
		what was affected -- the specific value changed. 
				Passwords and crypto keys are exempt.
				the old value is also desirable.
				Additionally the specific information
				used to enforce the policy that not everyone
				can do this.  Either privileges or
				authorizations that are enforced
				In this case a auth token would be included
				in the audit record specifying the
				solaris.isnsmgr.write authorization was used.
		when it happened -- not something applications have to
				supply if they have a proper audit context
				as in who did it.
		where it happened -- again this is from the proper audit
				context
		was the operation successful or
		did it fail and why it failed -- this needs to be supplied by
				the application.
  





The application iSNS server is making the change to the system and
should be responsible for handling the above 4 requirements.



I believe that the auditing requirements for a GUI are being met.



Vanessa





  
Vanessa> I believe this should give you the needed clarification.<br>

	Unfortunately not really.  It still sounds to me that this
	project doesn't adequately audit.

	I believe it's useful for this to be on record.

	I leave it to the committee to decide what to do with this information
	relative to the current project.

	The architectural policy is in support of the business requirement
	to evaluate and certify Solaris based on the Common Criteria
	Protection Profiles.
	There are other architectural policies such as Internationalization
	Compliance that fall into the same class of business requirement
	support.

Gary..
  






-- 

Vanessa L. Black 

Storage Platform Software Group

Sun Microsystems Inc.

Broomfield , Colorado


x72984, 303-272-2984





From sacadmin Fri Oct 10 12:00:44 2008
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9AJ0inK029026;
	Fri, 10 Oct 2008 12:00:44 -0700 (PDT)
Received: (from gww@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9AJ0ic9029025;
	Fri, 10 Oct 2008 12:00:44 -0700 (PDT)
Date: Fri, 10 Oct 2008 12:00:44 -0700 (PDT)
From: Gary Winiger 
Message-Id: <200810101900.m9AJ0ic9029025@sac.sfbay.sun.com>
To: Vanessa.Black@Sun.COM
Cc: LSARC@sac.sfbay.sun.com, gww@eng.sun.com, mk200726@sac.sfbay.sun.com
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
Status: RO
Content-Length: 3821

Vanessa,
	
	As you could see from my last comment, it's difficult to take apart
your HTML only mail.  Perhaps this is fine with all the LSARC members, but
for anyone trying to read the case log, it doesn't work well.  Try looking
at this case log through your browser.  Thus, I'm not going to include
what you wrote.

	I don't wish to belabor the issue if the committee and management
don't care to.
	Again, for the record, it is my opinion that the project team
doesn't understand what's required of by the policies related to Auditing.
It should be noted that Auditing is not the same as logging.  Auditing is
recording Audit Records in the Solaris Audit Trail using interfaces from
PSARC/2000/517 as contracted relative to PSARC/2003/397.  LSARC/2001/409
provides for contracted Java interfaces based on the preceding C interfaces.
	I wouldn't say that I understand the detail of Lockhart/Cacao or the
iSNS plug in, so it's not surprising that other project teams understand the
detail of Audit requirements.  That's what review is for.
	Cacao cannot do the Auditing for iSNS.  It doesn't know that it is
iSNS, nor what iSNS is being requested to do.  As I tried to previously
outline what is being done and what the (old and) new values or state is
required information to record in the Audit Record.  Saying user "fred" is
allowed authorization "solaris.foo.bar", in syslog or some other flat file
doesn't do that and isn't recording in the Solaris Audit Trail.  Auditing
needs to be done by the privileged "application" that not only has the
identified and authenticated user's original login "Audit Context" (as
supplemented by any role assumption), but also knows the policy it is
enforcing and the operation and change that is being done.
	Similarly, as I understand it, the iSNS server is not enforcing
the policy and doesn't have the user's/role's "Audit Context," thus can't
Audit.  It is certainly possible that a chain of appropriately privileged
processes can propagate the "Audit Context."  It is certainly possible that
the iSNS server given the user's/role's identity and "Audit Context" could
make the authorization check and correctly audit.
	Bottom line, in my opinion, the Auditing requirements do not
appear to be met by this project.  An Audit Trail example of me logging
in to my test machine, entering the root role, exiting that role and running
a command (mkdir) that I just granted myself when in the root role and
finally logging out would be:

header,69,2,login - ssh,,tundra,2008-10-07 16:27:32.218 -07:00
subject,gww,gww,staff,gww,staff,11376,2811845703,8789 22 marduk
return,success,0
header,69,2,role login,,tundra,2008-10-07 16:27:36.816 -07:00
subject,gww,root,root,root,root,11391,2811845703,8789 22 marduk
return,success,0
header,69,2,role logout,,tundra,2008-10-07 16:31:14.291 -07:00
subject,gww,root,root,root,root,11391,2811845703,8789 22 marduk
return,success,0
header,152,2,profile command,,tundra,2008-10-07 16:32:51.418 -07:00
subject,gww,root,staff,gww,staff,11423,2811845703,8789 22 marduk
path,/tmp
path,/usr/bin/mkdir
cmd,argcnt,3,-m,0,a/a,envcnt,0,
process,gww,root,staff,gww,staff,11423,2811845703,8789 22 marduk
return,success,0
header,69,2,logout,,tundra,2008-10-07 18:34:18.016 -07:00
subject,gww,gww,staff,gww,staff,11376,2811845703,8789 22 marduk
return,success,0

	Here the administrative action is making a root owned mode 0
subdirectory a/a in a similarly root owned directory a.
	
	To expand on the business requirement for administrative audit,
a number of verticals such as the financial, health and government sectors
have requirements for administrative audit as defined in the Audit Policy
for deploying systems in their environments.

	I hope I've given enough detail information for the committee (and
project team) to consider what to do.....

Gary..

From sacadmin Fri Oct 10 16:33:19 2008
Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9ANXJQk010363;
	Fri, 10 Oct 2008 16:33:19 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9ANXJdc041822;
	Fri, 10 Oct 2008 16:33:19 -0700 (PDT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9ANXJ8W024089;
	Fri, 10 Oct 2008 23:33:19 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0K8J00501QOJ1S00@mail-amer.sun.com>
 (original mail from Vanessa.Black@Sun.COM); Fri,
 10 Oct 2008 17:33:19 -0600 (MDT)
Received: from [172.20.26.30] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0K8J00F3OQRI9WG0@mail-amer.sun.com>; Fri,
 10 Oct 2008 17:33:18 -0600 (MDT)
Date: Fri, 10 Oct 2008 17:33:18 -0600
From: Vanessa Black 
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
In-reply-to: <200810101900.m9AJ0ic9029025@sac.sfbay.sun.com>
Sender: Vanessa.Black@Sun.COM
To: Gary Winiger 
Cc: LSARC@sac.sfbay.sun.com, gww@eng.sun.com, mk200726@sac.sfbay.sun.com,
        Robert Harryman 
Reply-to: Vanessa.Black@Sun.COM
Message-id: <48EFE63E.8070304@Sun.COM>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_b1gsi2ahQHIkABXaUnFk4A)"
References: <200810101900.m9AJ0ic9029025@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 11208

This is a multi-part message in MIME format.

--Boundary_(ID_b1gsi2ahQHIkABXaUnFk4A)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_b6Riqq392Cue03j5ujgoHQ)"


--Boundary_(ID_b6Riqq392Cue03j5ujgoHQ)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Gary,

I've changed my mail settings to send both text and html so I hope this 
message meets you favorably.

Thanks for the time you've put into helping us understand what is 
required to really implement the Solaris Audit Policy.
I've attached our proposal for the Audit Policy implementation in the 
iSNS gui. As you see, it is guided by your suggestions.

If you are satisfied by this proposal we can add it to the case material.

Vanessa
ps: I've cc'd Robert Harryman - he is a member of the project team.

Gary Winiger wrote:
> Vanessa,
> 	
> 	As you could see from my last comment, it's difficult to take apart
> your HTML only mail.  Perhaps this is fine with all the LSARC members, but
> for anyone trying to read the case log, it doesn't work well.  Try looking
> at this case log through your browser.  Thus, I'm not going to include
> what you wrote.
>
> 	I don't wish to belabor the issue if the committee and management
> don't care to.
> 	Again, for the record, it is my opinion that the project team
> doesn't understand what's required of by the policies related to Auditing.
> It should be noted that Auditing is not the same as logging.  Auditing is
> recording Audit Records in the Solaris Audit Trail using interfaces from
> PSARC/2000/517 as contracted relative to PSARC/2003/397.  LSARC/2001/409
> provides for contracted Java interfaces based on the preceding C interfaces.
> 	I wouldn't say that I understand the detail of Lockhart/Cacao or the
> iSNS plug in, so it's not surprising that other project teams understand the
> detail of Audit requirements.  That's what review is for.
> 	Cacao cannot do the Auditing for iSNS.  It doesn't know that it is
> iSNS, nor what iSNS is being requested to do.  As I tried to previously
> outline what is being done and what the (old and) new values or state is
> required information to record in the Audit Record.  Saying user "fred" is
> allowed authorization "solaris.foo.bar", in syslog or some other flat file
> doesn't do that and isn't recording in the Solaris Audit Trail.  Auditing
> needs to be done by the privileged "application" that not only has the
> identified and authenticated user's original login "Audit Context" (as
> supplemented by any role assumption), but also knows the policy it is
> enforcing and the operation and change that is being done.
> 	Similarly, as I understand it, the iSNS server is not enforcing
> the policy and doesn't have the user's/role's "Audit Context," thus can't
> Audit.  It is certainly possible that a chain of appropriately privileged
> processes can propagate the "Audit Context."  It is certainly possible that
> the iSNS server given the user's/role's identity and "Audit Context" could
> make the authorization check and correctly audit.
> 	Bottom line, in my opinion, the Auditing requirements do not
> appear to be met by this project.  An Audit Trail example of me logging
> in to my test machine, entering the root role, exiting that role and running
> a command (mkdir) that I just granted myself when in the root role and
> finally logging out would be:
>
> header,69,2,login - ssh,,tundra,2008-10-07 16:27:32.218 -07:00
> subject,gww,gww,staff,gww,staff,11376,2811845703,8789 22 marduk
> return,success,0
> header,69,2,role login,,tundra,2008-10-07 16:27:36.816 -07:00
> subject,gww,root,root,root,root,11391,2811845703,8789 22 marduk
> return,success,0
> header,69,2,role logout,,tundra,2008-10-07 16:31:14.291 -07:00
> subject,gww,root,root,root,root,11391,2811845703,8789 22 marduk
> return,success,0
> header,152,2,profile command,,tundra,2008-10-07 16:32:51.418 -07:00
> subject,gww,root,staff,gww,staff,11423,2811845703,8789 22 marduk
> path,/tmp
> path,/usr/bin/mkdir
> cmd,argcnt,3,-m,0,a/a,envcnt,0,
> process,gww,root,staff,gww,staff,11423,2811845703,8789 22 marduk
> return,success,0
> header,69,2,logout,,tundra,2008-10-07 18:34:18.016 -07:00
> subject,gww,gww,staff,gww,staff,11376,2811845703,8789 22 marduk
> return,success,0
>
> 	Here the administrative action is making a root owned mode 0
> subdirectory a/a in a similarly root owned directory a.
> 	
> 	To expand on the business requirement for administrative audit,
> a number of verticals such as the financial, health and government sectors
> have requirements for administrative audit as defined in the Audit Policy
> for deploying systems in their environments.
>
> 	I hope I've given enough detail information for the committee (and
> project team) to consider what to do.....
>
> Gary..
>   

-- 
Vanessa L. Black
Storage Platform Software Group
Sun Microsystems Inc.
Broomfield , Colorado
x72984, 303-272-2984

--Boundary_(ID_b6Riqq392Cue03j5ujgoHQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  


Gary,



I've changed my mail settings to send both text and html so I hope this
message meets you favorably.



Thanks for the time you've put into helping us understand what is
required to really implement the Solaris Audit Policy. 

I've attached our proposal for the Audit Policy implementation in the
iSNS gui. As you see, it is guided by your suggestions.



If you are satisfied by this proposal we can add it to the case
material.



Vanessa

ps: I've cc'd Robert Harryman - he is a member of the project team.



Gary Winiger wrote:


  
Vanessa,
	
	As you could see from my last comment, it's difficult to take apart
your HTML only mail.  Perhaps this is fine with all the LSARC members, but
for anyone trying to read the case log, it doesn't work well.  Try looking
at this case log through your browser.  Thus, I'm not going to include
what you wrote.

	I don't wish to belabor the issue if the committee and management
don't care to.
	Again, for the record, it is my opinion that the project team
doesn't understand what's required of by the policies related to Auditing.
It should be noted that Auditing is not the same as logging.  Auditing is
recording Audit Records in the Solaris Audit Trail using interfaces from
PSARC/2000/517 as contracted relative to PSARC/2003/397.  LSARC/2001/409
provides for contracted Java interfaces based on the preceding C interfaces.
	I wouldn't say that I understand the detail of Lockhart/Cacao or the
iSNS plug in, so it's not surprising that other project teams understand the
detail of Audit requirements.  That's what review is for.
	Cacao cannot do the Auditing for iSNS.  It doesn't know that it is
iSNS, nor what iSNS is being requested to do.  As I tried to previously
outline what is being done and what the (old and) new values or state is
required information to record in the Audit Record.  Saying user "fred" is
allowed authorization "solaris.foo.bar", in syslog or some other flat file
doesn't do that and isn't recording in the Solaris Audit Trail.  Auditing
needs to be done by the privileged "application" that not only has the
identified and authenticated user's original login "Audit Context" (as
supplemented by any role assumption), but also knows the policy it is
enforcing and the operation and change that is being done.
	Similarly, as I understand it, the iSNS server is not enforcing
the policy and doesn't have the user's/role's "Audit Context," thus can't
Audit.  It is certainly possible that a chain of appropriately privileged
processes can propagate the "Audit Context."  It is certainly possible that
the iSNS server given the user's/role's identity and "Audit Context" could
make the authorization check and correctly audit.
	Bottom line, in my opinion, the Auditing requirements do not
appear to be met by this project.  An Audit Trail example of me logging
in to my test machine, entering the root role, exiting that role and running
a command (mkdir) that I just granted myself when in the root role and
finally logging out would be:

header,69,2,login - ssh,,tundra,2008-10-07 16:27:32.218 -07:00
subject,gww,gww,staff,gww,staff,11376,2811845703,8789 22 marduk
return,success,0
header,69,2,role login,,tundra,2008-10-07 16:27:36.816 -07:00
subject,gww,root,root,root,root,11391,2811845703,8789 22 marduk
return,success,0
header,69,2,role logout,,tundra,2008-10-07 16:31:14.291 -07:00
subject,gww,root,root,root,root,11391,2811845703,8789 22 marduk
return,success,0
header,152,2,profile command,,tundra,2008-10-07 16:32:51.418 -07:00
subject,gww,root,staff,gww,staff,11423,2811845703,8789 22 marduk
path,/tmp
path,/usr/bin/mkdir
cmd,argcnt,3,-m,0,a/a,envcnt,0,
process,gww,root,staff,gww,staff,11423,2811845703,8789 22 marduk
return,success,0
header,69,2,logout,,tundra,2008-10-07 18:34:18.016 -07:00
subject,gww,gww,staff,gww,staff,11376,2811845703,8789 22 marduk
return,success,0

	Here the administrative action is making a root owned mode 0
subdirectory a/a in a similarly root owned directory a.
	
	To expand on the business requirement for administrative audit,
a number of verticals such as the financial, health and government sectors
have requirements for administrative audit as defined in the Audit Policy
for deploying systems in their environments.

	I hope I've given enough detail information for the committee (and
project team) to consider what to do.....

Gary..
  






-- 

Vanessa L. Black 

Storage Platform Software Group

Sun Microsystems Inc.

Broomfield , Colorado


x72984, 303-272-2984





--Boundary_(ID_b6Riqq392Cue03j5ujgoHQ)--

--Boundary_(ID_b1gsi2ahQHIkABXaUnFk4A)
Content-type: text/plain; name=Audit_Policy.txt
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=Audit_Policy.txt



Proposal for implementing Audit Policy for iSNS Gui (LSARC/2008/627)

The iSNS Gui web application will supply the following information as Audit Records  in the Solaris Audit Trail

-The iSNS configuration that occurred
-The identified and authenticated system user audit context as set by the system login method through pam_unix_cred which will include when and where this configuration occurs.
-The specific value changed and the authorization that was enforced. In the case of this project, the fact that solaris.isnsmgr.write was used.
-The success/failure of the operation and why it failed.

Implementation will be provided for with the Java interfaces described in LSARC/2001/409.
				

--Boundary_(ID_b1gsi2ahQHIkABXaUnFk4A)--

From sacadmin Tue Oct 14 09:05:18 2008
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9EG5Ibb007349;
	Tue, 14 Oct 2008 09:05:18 -0700 (PDT)
Received: (from gww@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9EG5IVC007348;
	Tue, 14 Oct 2008 09:05:18 -0700 (PDT)
Date: Tue, 14 Oct 2008 09:05:18 -0700 (PDT)
From: Gary Winiger 
Message-Id: <200810141605.m9EG5IVC007348@sac.sfbay.sun.com>
To: Vanessa.Black@Sun.COM
Cc: LSARC@sac.sfbay.sun.com, Robert.Harryman@Sun.COM, gww@eng.sun.com,
        mk200726@sac.sfbay.sun.com
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
Status: RO
Content-Length: 371

> I've changed my mail settings to send both text and html so I hope this 
> message meets you favorably.

> 
> Thanks for the time you've put into helping us understand what is 
> required to really implement the Solaris Audit Policy.

	I've been having VPN problems.  While I believe this is
	converged, I'd like to have to the end of the day to reply.

Thankx,
Gary..

From sacadmin Wed Oct 15 07:52:32 2008
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9FEqWRq019839;
	Wed, 15 Oct 2008 07:52:32 -0700 (PDT)
Received: (from gww@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9FEqWNM019838;
	Wed, 15 Oct 2008 07:52:32 -0700 (PDT)
Date: Wed, 15 Oct 2008 07:52:32 -0700 (PDT)
From: Gary Winiger 
Message-Id: <200810151452.m9FEqWNM019838@sac.sfbay.sun.com>
To: Vanessa.Black@Sun.COM, gww@sac.sfbay.sun.com
Cc: LSARC@sac.sfbay.sun.com, Robert.Harryman@Sun.COM, gww@eng.sun.com,
        mk200726@sac.sfbay.sun.com
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
Status: RO
Content-Length: 1756

> Proposal for implementing Audit Policy for iSNS Gui (LSARC/2008/627)
> 
> The iSNS Gui web application will supply the following information as Audit
> Records  in the Solaris Audit Trail
> 
> -The iSNS configuration that occurred
> -The identified and authenticated system user audit context as set by the
>  system login method through pam_unix_cred which will include when and where
>  this configuration occurs.
> -The specific value changed and the authorization that was enforced. In the
>  case of this project, the fact that solaris.isnsmgr.write was used.
> -The success/failure of the operation and why it failed.
> 
> Implementation will be provided for with the Java interfaces described
> in LSARC/2001/409.

	I believe this covers the idea and intent, though the detail
	seems incomplete.  For this case, I believe it is sufficient
	to update the spec to show an import dependency on
	LSARC/2001/409 (Java Audit Session for Viper and WBEM),
	PSARC/2000/517 (Thread-safe audit API),
	PSARC/2003/397 (Contracted audit interfaces for open source)
	and an integration dependency on contracts for use of the Solaris
	and Java Audit API.  I don't believe this case is either Viper
	(Seabreaze) or WBEM, thus the class definitions for Viper and
	WBEM don't directly apply.
	(So, I guess I'm asking for a spec update before this case
	closes.  That update should probably also include clarification
	of the PAM and Authorization specifications that came out during
	the discussion.)

	The Solaris Audit Project team will need to be involved to
	help specify and verify the proper audit records, do the
	contractual work and assist as needed with implementation
	details.  I'm a good place to start with for Audit Project Team
	involvement.

Gary..

From sacadmin Wed Oct 15 15:45:06 2008
Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9FMj64o018582;
	Wed, 15 Oct 2008 15:45:06 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31])
	by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9FMj66k015064;
	Wed, 15 Oct 2008 15:45:06 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9FMj5B5007652;
	Wed, 15 Oct 2008 22:45:05 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0K8S00G01XHJJ800@mail-amer.sun.com>
 (original mail from Vanessa.Black@Sun.COM); Wed,
 15 Oct 2008 16:45:05 -0600 (MDT)
Received: from [172.20.26.30] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0K8S0029VXUKPB00@mail-amer.sun.com>; Wed,
 15 Oct 2008 16:44:44 -0600 (MDT)
Date: Wed, 15 Oct 2008 16:44:44 -0600
From: Vanessa Black 
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
In-reply-to: <200810151452.m9FEqWNM019838@sac.sfbay.sun.com>
Sender: Vanessa.Black@Sun.COM
To: Gary Winiger 
Cc: LSARC@sac.sfbay.sun.com, Robert.Harryman@Sun.COM, gww@eng.sun.com,
        mk200726@sac.sfbay.sun.com
Reply-to: Vanessa.Black@Sun.COM
Message-id: <48F6725C.2030705@Sun.COM>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Yzir7HWOz2aeMku03iHYtQ)"
References: <200810151452.m9FEqWNM019838@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 5683

This is a multi-part message in MIME format.

--Boundary_(ID_Yzir7HWOz2aeMku03iHYtQ)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT



Gary Winiger wrote:
>> Proposal for implementing Audit Policy for iSNS Gui (LSARC/2008/627)
>>
>> The iSNS Gui web application will supply the following information as Audit
>> Records  in the Solaris Audit Trail
>>
>> -The iSNS configuration that occurred
>> -The identified and authenticated system user audit context as set by the
>>  system login method through pam_unix_cred which will include when and where
>>  this configuration occurs.
>> -The specific value changed and the authorization that was enforced. In the
>>  case of this project, the fact that solaris.isnsmgr.write was used.
>> -The success/failure of the operation and why it failed.
>>
>> Implementation will be provided for with the Java interfaces described
>> in LSARC/2001/409.
>>     
>
> 	I believe this covers the idea and intent, though the detail
> 	seems incomplete.  For this case, I believe it is sufficient
> 	to update the spec to show an import dependency on
> 	LSARC/2001/409 (Java Audit Session for Viper and WBEM),
> 	PSARC/2000/517 (Thread-safe audit API),
> 	PSARC/2003/397 (Contracted audit interfaces for open source)
> 	and an integration dependency on contracts for use of the Solaris
> 	and Java Audit API.  I don't believe this case is either Viper
> 	(Seabreaze) or WBEM, thus the class definitions for Viper and
> 	WBEM don't directly apply.
> 	(So, I guess I'm asking for a spec update before this case
> 	closes.  That update should probably also include clarification
> 	of the PAM and Authorization specifications that came out during
> 	the discussion.)
>
> 	The Solaris Audit Project team will need to be involved to
> 	help specify and verify the proper audit records, do the
> 	contractual work and assist as needed with implementation
> 	details.  I'm a good place to start with for Audit Project Team
> 	involvement.
>   
We'll update the spec with:
- the import dependencies as you mention
- the clarification of the use of PAM and RBAC authorizations.

We'll also involve you, to get Solaris Audit Project Team involvement, 
to ensure that we are implementing the Solaris Audit Policy correctly.

Vanessa


> Gary..
>   

-- 
Vanessa L. Black
Storage Platform Software Group
Sun Microsystems Inc.
Broomfield , Colorado
x72984, 303-272-2984

--Boundary_(ID_Yzir7HWOz2aeMku03iHYtQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  






Gary Winiger wrote:


  

    
Proposal for implementing Audit Policy for iSNS Gui (LSARC/2008/627)

The iSNS Gui web application will supply the following information as Audit
Records  in the Solaris Audit Trail

-The iSNS configuration that occurred
-The identified and authenticated system user audit context as set by the
 system login method through pam_unix_cred which will include when and where
 this configuration occurs.
-The specific value changed and the authorization that was enforced. In the
 case of this project, the fact that solaris.isnsmgr.write was used.
-The success/failure of the operation and why it failed.

Implementation will be provided for with the Java interfaces described
in LSARC/2001/409.
    

  

  

	I believe this covers the idea and intent, though the detail
	seems incomplete.  For this case, I believe it is sufficient
	to update the spec to show an import dependency on
	LSARC/2001/409 (Java Audit Session for Viper and WBEM),
	PSARC/2000/517 (Thread-safe audit API),
	PSARC/2003/397 (Contracted audit interfaces for open source)
	and an integration dependency on contracts for use of the Solaris
	and Java Audit API.  I don't believe this case is either Viper
	(Seabreaze) or WBEM, thus the class definitions for Viper and
	WBEM don't directly apply.
	(So, I guess I'm asking for a spec update before this case
	closes.  That update should probably also include clarification
	of the PAM and Authorization specifications that came out during
	the discussion.)

	The Solaris Audit Project team will need to be involved to
	help specify and verify the proper audit records, do the
	contractual work and assist as needed with implementation
	details.  I'm a good place to start with for Audit Project Team
	involvement.
  



We'll update the spec with:

- the import dependencies as you mention 

- the clarification of the use of PAM and RBAC authorizations. 



We'll also involve you, to get Solaris Audit Project Team involvement,
to ensure that we are implementing the Solaris Audit Policy correctly.



Vanessa







  
Gary..
  






-- 

Vanessa L. Black 

Storage Platform Software Group

Sun Microsystems Inc.

Broomfield , Colorado


x72984, 303-272-2984





--Boundary_(ID_Yzir7HWOz2aeMku03iHYtQ)--

From sacadmin Wed Oct 15 16:06:21 2008
Received: from dm-eng-02.sfbay.sun.com (dm-eng-02.SFBay.Sun.COM [129.146.11.32])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9FN6Lfi019638;
	Wed, 15 Oct 2008 16:06:21 -0700 (PDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9FN6KaM035739;
	Wed, 15 Oct 2008 16:06:20 -0700 (PDT)
Received: from marduk.eng.sun.com (localhost [127.0.0.1])
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m9FN7SUt019130;
	Wed, 15 Oct 2008 16:07:28 -0700 (PDT)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m9FN7S6s019129;
	Wed, 15 Oct 2008 16:07:28 -0700 (PDT)
Date: Wed, 15 Oct 2008 16:07:28 -0700 (PDT)
From: Gary Winiger 
Message-Id: <200810152307.m9FN7S6s019129@marduk.eng.sun.com>
To: gww@sac.sfbay.sun.com, Vanessa.Black@sun.com
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
Cc: LSARC@sac.sfbay.sun.com, Robert.Harryman@sun.com, gww@eng.sun.com,
        mk200726@sac.sfbay.sun.com
X-Sun-Charset: US-ASCII
Status: RO
Content-Length: 168

> We'll also involve you, to get Solaris Audit Project Team involvement, 
> to ensure that we are implementing the Solaris Audit Policy correctly.

	Thanks.
+1

Gary..

From sacadmin Tue Oct 21 10:17:39 2008
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LHHdAR012141;
	Tue, 21 Oct 2008 10:17:39 -0700 (PDT)
Received: (from gww@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9LHHcv2012140;
	Tue, 21 Oct 2008 10:17:38 -0700 (PDT)
Date: Tue, 21 Oct 2008 10:17:38 -0700 (PDT)
From: Gary Winiger 
Message-Id: <200810211717.m9LHHcv2012140@sac.sfbay.sun.com>
To: Vanessa.Black@sun.com, gww@eng.sun.com, gww@sac.sfbay.sun.com
Cc: LSARC@sac.sfbay.sun.com, Robert.Harryman@sun.com,
        mk200726@sac.sfbay.sun.com
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
Status: RO
Content-Length: 472

For there record from today's LSARC meeting, this case does not seem
to have completed.  The IAM file still shows waiting fast track
and exposure closed.  The spec has not been updated.

As I understand things, the case's exposure is actually open,
so it would be reasonable to restart it with the updated spec
as an open case to allow the community to see it.  The case log
should be redacted and the case should follow the +1 policy
once its exposure is opened.

Gary..

From sacadmin Tue Oct 21 10:35:31 2008
Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LHZVfa012386;
	Tue, 21 Oct 2008 10:35:31 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LHZU1w060906;
	Tue, 21 Oct 2008 10:35:31 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9LHZULa015646;
	Tue, 21 Oct 2008 17:35:30 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0K9300M01MVIVX00@mail-amer.sun.com>
 (original mail from Vanessa.Black@Sun.COM); Tue,
 21 Oct 2008 11:35:30 -0600 (MDT)
Received: from [172.20.26.30] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0K93006OPNIZ0BC0@mail-amer.sun.com>; Tue,
 21 Oct 2008 11:35:23 -0600 (MDT)
Date: Tue, 21 Oct 2008 11:35:23 -0600
From: Vanessa Black 
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
In-reply-to: <200810211717.m9LHHcv2012140@sac.sfbay.sun.com>
Sender: Vanessa.Black@Sun.COM
To: Gary Winiger 
Cc: gww@eng.sun.com, LSARC@sac.sfbay.sun.com, Robert.Harryman@Sun.COM,
        mk200726@sac.sfbay.sun.com
Reply-to: Vanessa.Black@Sun.COM
Message-id: <48FE12DB.1020808@Sun.COM>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_9xKxLNHYQt6FGHF6n1rKrg)"
References: <200810211717.m9LHHcv2012140@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 2854

This is a multi-part message in MIME format.

--Boundary_(ID_9xKxLNHYQt6FGHF6n1rKrg)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT


Hi Gary,

I worked up the update to the spec on Friday - but it seems that we had 
a problem with actually getting it into the case materials fully. We're 
straightening this out on our side. Our intention was to have had the 
spec updated by the end of last week.

Vanessa

Gary Winiger wrote:
> For there record from today's LSARC meeting, this case does not seem
> to have completed.  The IAM file still shows waiting fast track
> and exposure closed.  The spec has not been updated.
>
> As I understand things, the case's exposure is actually open,
> so it would be reasonable to restart it with the updated spec
> as an open case to allow the community to see it.  The case log
> should be redacted and the case should follow the +1 policy
> once its exposure is opened.
>
> Gary..
>   

-- 
Vanessa L. Black
Storage Platform Software Group
Sun Microsystems Inc.
Broomfield , Colorado
x72984, 303-272-2984

--Boundary_(ID_9xKxLNHYQt6FGHF6n1rKrg)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  




Hi Gary,



I worked up the update to the spec on Friday - but it seems that we had
a problem with actually getting it into the case materials fully. We're
straightening this out on our side. Our intention was to have had the
spec updated by the end of last week.



Vanessa



Gary Winiger wrote:


  
For there record from today's LSARC meeting, this case does not seem
to have completed.  The IAM file still shows waiting fast track
and exposure closed.  The spec has not been updated.

As I understand things, the case's exposure is actually open,
so it would be reasonable to restart it with the updated spec
as an open case to allow the community to see it.  The case log
should be redacted and the case should follow the +1 policy
once its exposure is opened.

Gary..
  






-- 

Vanessa L. Black 

Storage Platform Software Group

Sun Microsystems Inc.

Broomfield , Colorado


x72984, 303-272-2984





--Boundary_(ID_9xKxLNHYQt6FGHF6n1rKrg)--

From sacadmin Tue Oct 21 14:45:30 2008
Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9LLjUZ0022254;
	Tue, 21 Oct 2008 14:45:30 -0700 (PDT)
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9LLjUIa036571;
	Tue, 21 Oct 2008 14:45:30 -0700 (PDT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9LLjUbn002630;
	Tue, 21 Oct 2008 21:45:30 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0K9300601Z0W0300@mail-amer.sun.com>
 (original mail from Vanessa.Black@Sun.COM); Tue,
 21 Oct 2008 15:45:30 -0600 (MDT)
Received: from [172.20.26.30] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0K9300J9UZ3JWD30@mail-amer.sun.com>; Tue,
 21 Oct 2008 15:45:20 -0600 (MDT)
Date: Tue, 21 Oct 2008 15:45:19 -0600
From: Vanessa Black 
Subject: Re: iSNS GUI [LSARC/2008/627 FastTrack timeout 10/13/2008]
In-reply-to: <200810211717.m9LHHcv2012140@sac.sfbay.sun.com>
Sender: Vanessa.Black@Sun.COM
To: Gary Winiger 
Cc: gww@eng.sun.com, LSARC@sac.sfbay.sun.com, Robert.Harryman@Sun.COM,
        mk200726@sac.sfbay.sun.com
Reply-to: Vanessa.Black@Sun.COM
Message-id: <48FE4D6F.3060605@Sun.COM>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_1oWM29uzeLomD7KLN0AyXA)"
References: <200810211717.m9LHHcv2012140@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 2726

This is a multi-part message in MIME format.

--Boundary_(ID_1oWM29uzeLomD7KLN0AyXA)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Hi Folks,

The spec is now updated at:

http://sac.eng/arc/LSARC/2008/627/20081006_vanessa.black
The security impact section has been updated.


Vanessa

Gary Winiger wrote:
> For there record from today's LSARC meeting, this case does not seem
> to have completed.  The IAM file still shows waiting fast track
> and exposure closed.  The spec has not been updated.
>
> As I understand things, the case's exposure is actually open,
> so it would be reasonable to restart it with the updated spec
> as an open case to allow the community to see it.  The case log
> should be redacted and the case should follow the +1 policy
> once its exposure is opened.
>
> Gary..
>   

-- 
Vanessa L. Black
Storage Platform Software Group
Sun Microsystems Inc.
Broomfield , Colorado
x72984, 303-272-2984

--Boundary_(ID_1oWM29uzeLomD7KLN0AyXA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  


Hi Folks,



The spec is now updated at:



http://sac.eng/arc/LSARC/2008/627/20081006_vanessa.black

The security impact section has been updated.





Vanessa



Gary Winiger wrote:


  
For there record from today's LSARC meeting, this case does not seem
to have completed.  The IAM file still shows waiting fast track
and exposure closed.  The spec has not been updated.

As I understand things, the case's exposure is actually open,
so it would be reasonable to restart it with the updated spec
as an open case to allow the community to see it.  The case log
should be redacted and the case should follow the +1 policy
once its exposure is opened.

Gary..
  






-- 

Vanessa L. Black 

Storage Platform Software Group

Sun Microsystems Inc.

Broomfield , Colorado


x72984, 303-272-2984





--Boundary_(ID_1oWM29uzeLomD7KLN0AyXA)--