From markcarl@sac.sfbay.sun.com Mon Jan 19 22:01:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0K61R0i013948 for ; Mon, 19 Jan 2009 22:01:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0K61I2p023435; Mon, 19 Jan 2009 23:01:27 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDR00213A2DX100@nwk-avmta-2.sfbay.sun.com>; Mon, 19 Jan 2009 22:01:25 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDR0084IA2DTYC0@nwk-avmta-2.sfbay.sun.com>; Mon, 19 Jan 2009 22:01:25 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0K61N4C038020; Mon, 19 Jan 2009 22:01:23 -0800 (PST) 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 n0K61Mqw013943; Mon, 19 Jan 2009 22:01:22 -0800 (PST) Received: (from markcarl@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n0K61Mhs013939; Mon, 19 Jan 2009 22:01:22 -0800 (PST) Date: Mon, 19 Jan 2009 22:01:22 -0800 (PST) From: Mark Carlson Subject: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] To: LSARC-ext@sun.com Cc: Srirama.Sharma@sun.com Message-id: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 11756 I am sponsoring this familiarity case for Srirama Sharma, requesting minor binding and timing out on 1/26/2009. -- mark Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Openwsman 1.2. Name of Document Author/Supplier: Author: Srirama Sharma 1.3 Date of This Document: 19 January, 2009 2.0 Project Summary 2.1 Project Description This project introduces the package of Openwsman 2.1.0 into the SFW consolidation. 4. Technical Description Openwsman is a project intended to provide an open-source implementation of the Web Services Management specification (WS-Management) and to expose system management information on the Linux operating system using the WS-Management protocol. WS-Management is based on a suite of web services specifications and usage requirements that exposes a set of operations focused on and covers all system management aspects. Command name Notes ======================================== openwsmand Openwsman daemon 5. Interfaces 5.1 Exported Interfaces Interface Name Classification Comments ------------------------------------------------------- --------------- --------------------------- SUNWopenwsmanu Uncommitted Openwsman user package SUNWopenwsmanr Uncommitted Openwsman root package /usr/sbin/openwsmand Uncommitted Daemon /usr/lib/libwsman.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman.so->libwsman.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman.so.1->libwsman.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_curl_client_transport.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_curl_client_transport.so->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_curl_client_transport.so.1->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_client.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_client.so->libwsman_client.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_client.so.1->libwsman_client.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_server.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_server.so->libwsman_server.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_server.so.1->libwsman_server.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_clientpp.so.0.0.0 Uncommitted Shared library /usr/lib/libwsman_clientpp.so->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link /usr/lib/libwsman_clientpp.so.0->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link /usr/lib/openwsman/ Uncommitted Dir where openwsman libraries are installed /usr/lib/openwsman/plugins Uncommitted Dir where plugins are installed /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/plugins/libwsman_identify_plugin.so->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_test.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/plugins/libwsman_test.so->libwsman_test.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_test.so.1->libwsman_test.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/authenticators Uncommitted Dir where authenticator libraries are installed /usr/lib/openwsman/authenticators/libwsman_file_auth.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/authenticators/libwsman_pam_auth.so->libwsman_file_auth.so.1.0.0 Uncommitted Sy mbolic link /usr/lib/openwsman/authenticators/libwsman_pam_auth.so.1->libwsman_file_auth.so.1.0.0 Uncommitted Symbolic link /usr/lib/pkgconfig/openwsman-server.pc Uncommitted Pkgconfig file /usr/lib/pkgconfig/openwsman++.pc Uncommitted Pkgconfig file /usr/lib/pkgconfig/openwsman.pc Uncommitted Pkgconfig file /usr/include/openwsman Uncommitted Dir where openwsman headers are installed. /usr/include/openwsman/wsman-types.h Uncommitted Header file /usr/include/openwsman/wsman-names.h Uncommitted Header file /usr/include/openwsman/wsman-debug.h Uncommitted Header file /usr/include/openwsman/wsman-client.h Uncommitted Header file /usr/include/openwsman/wsman-client-api.h Uncommitted Header file /usr/include/openwsman/wsman-xml-api.h Uncommitted Header file /usr/include/openwsman/wsman-client-transport.h Uncommitted Header file /usr/include/openwsman/wsman-xml-serializer.h Uncommitted Header file /usr/include/openwsman/wsman-xml-serialize.h Uncommitted Header file /usr/include/openwsman/wsman-server-api.h Uncommitted Header file /usr/include/openwsman/wsman-faults.h Uncommitted Header file /usr/include/openwsman/wsman-soap-message.h Uncommitted Header file /usr/include/openwsman/wsman-api.h Uncommitted Header file /usr/include/openwsman/wsman-declarations.h Uncommitted Header file /usr/include/openwsman/wsman-soap.h Uncommitted Header file /usr/include/openwsman/wsman-epr.h Uncommitted Header file /usr/include/openwsman/wsman-filter.h Uncommitted Header file /usr/include/openwsman/wsman-soap-envelope.h Uncommitted Header file /usr/include/openwsman/wsman-subscription-repository.h Uncommitted Header file /usr/include/openwsman/wsman-event-pool.h Uncommitted Header file /usr/include/openwsman/wsman-cimindication-processor.h Uncommitted Header file /usr/include/openwsman/u/buf.h Uncommitted Header file /usr/include/openwsman/u/carpal.h Uncommitted Header file /usr/include/openwsman/u/libu.h Uncommitted Header file /usr/include/openwsman/u/log.h Uncommitted Header file /usr/include/openwsman/u/logprv.h Uncommitted Header file /usr/include/openwsman/u/memory.h Uncommitted Header file /usr/include/openwsman/u/misc.h Uncommitted Header file /usr/include/openwsman/u/os.h Uncommitted Header file /usr/include/openwsman/u/uri.h Uncommitted Header file /usr/include/openwsman/u/uuid.h Uncommitted Header file /usr/include/openwsman/u/lock.h Uncommitted Header file /usr/include/openwsman/u/strings.h Uncommitted Header file /usr/include/openwsman/u/md5.h Uncommitted Header file /usr/include/openwsman/u/list.h Uncommitted Header file /usr/include/openwsman/u/hash.h Uncommitted Header file /usr/include/openwsman/u/base64.h Uncommitted Header file /usr/include/openwsman/u/iniparser.h Uncommitted Header file /usr/include/openwsman/u/debug.h Uncommitted Header file /usr/include/openwsman/u/uerr.h Uncommitted Header file /usr/include/openwsman/u/uoption.h Uncommitted Header file /usr/include/openwsman/u/gettimeofday.h Uncommitted Header file /usr/include/openwsman/u/syslog.h Uncommitted Header file /usr/include/openwsman/u/pthreadx.h Uncommitted Header file /usr/include/openwsman/cim/cim-interface.h Uncommitted Header file /usr/include/openwsman/cpp/OpenWsmanClient.h Uncommitted Header file /usr/include/openwsman/cpp/Exception.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanClient.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanEPR.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanFilter.h Uncommitted Header file /usr/share/man/man8/openwsmand.8 Uncommitted Manpage /etc/openwsman Uncommitted Dir where openwsman config files are installed /etc/openwsman/owsmangencert.sh Uncommitted Script /etc/openwsman/openwsman.conf Uncommitted Config file /etc/openwsman/ssleay.cnf Uncommitted Config file /var/svc/manifest/network/openwsmasnd.xml Uncommitted SVC Manifest file /lib/svc/method/svc-openwsmand Uncommitted SVC Method file Ports 8889 and 8888 Uncommitted Recommended ports for WS-Management 5.2. Imported Interfaces Interface Name Classification Comments --------------------------- ---------------- --------------------------------- /usr/lib/libcurl.so.3 Uncommitted library provided by SUNWcurl pkg /usr/lib/libgss.so.1 Uncommitted library provided by SUNWgss /usr/lib/libidn.so.11 Uncommitted library provided by SUNWgnu-idn /lib/libz.so.1 Uncommitted library provided by SUNWzlibr /lib/libcrypto.so.0.9.8 Uncommitted library provided by SUNWopenssl-libraries /lib/libssl.so.0.9.8 Uncommitted library provided by SUNWopenssl-libraries /lib/libxml2.so.2 Uncommitted library provided by SUNWlxmlr Ports 5988/5989 Uncommitted Port through which the daemon connects to cimserver through CIM-XML. 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 Peter.Schow@sun.com Tue Jan 20 07:45:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KFjIwa028708 for ; Tue, 20 Jan 2009 07:45:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0KFix5B022528 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Tue, 20 Jan 2009 23:45:17 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00F3H13GG400@brm-avmta-1.central.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 20 Jan 2009 08:45:16 -0700 (MST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00AIF13FPI40@brm-avmta-1.central.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 20 Jan 2009 08:45:15 -0700 (MST) Received: from ferpo (ferpo.Central.Sun.COM [129.147.49.234]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with SMTP id n0KFjCXO063524; Tue, 20 Jan 2009 08:45:12 -0700 (MST) Received: by ferpo (sSMTP sendmail emulation); Tue, 20 Jan 2009 08:45:12 -0700 Date: Tue, 20 Jan 2009 08:45:12 -0700 From: Peter Schow Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> To: Mark Carlson Cc: LSARC-ext@sun.com, Srirama.Sharma@sun.com Message-id: <20090120154512.GA22307@ferpo.Central.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1605 On Mon, Jan 19, 2009 at 10:01:22PM -0800, Mark Carlson wrote: > I am sponsoring this familiarity case for Srirama Sharma, requesting > minor binding and timing out on 1/26/2009. > > -- mark > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Openwsman > 1.2. Name of Document Author/Supplier: > Author: Srirama Sharma > 1.3 Date of This Document: > 19 January, 2009 > > 2.0 Project Summary > 2.1 Project Description > > This project introduces the package of Openwsman 2.1.0 > into the SFW consolidation. > > > 4. Technical Description > > Openwsman is a project intended to provide an open-source implementation of the > Web Services Management specification (WS-Management) and to expose system management > information on the Linux operating system using the WS-Management protocol. > > WS-Management is based on a suite of web services specifications and usage requirements > that exposes a set of operations focused on and covers all system management aspects. 1. It would be nice to see the small openwsman CLI (wsman) bundled into SUNWopenwsmanu as well. I've found it to be invaluable for openwsman testing and verification purposes. 2. The description says that openwsman will expose system instrumentation on Linux. What will it do on Solaris? Is a CIM server forthcoming in a later case? 3. The openwsman library generates and uses UUIDs; you'll probably want to include libuuid in your imports. From John.Fischer@sun.com Tue Jan 20 08:04:30 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KG4TtI005309 for ; Tue, 20 Jan 2009 08:04:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0KG4JtM026704 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 20 Jan 2009 16:04:28 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00J331ZE7N00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 20 Jan 2009 08:04:26 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00E9P1ZCYCA0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 20 Jan 2009 08:04:24 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0KG4OxM016878 for ; Tue, 20 Jan 2009 16:04:24 +0000 (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 <0KDS00F010JBX900@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 20 Jan 2009 09:04:24 -0700 (MST) Received: from 129.145.154.112 ([129.145.154.112]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDS00HX81YYP940@mail-amer.sun.com>; Tue, 20 Jan 2009 09:04:11 -0700 (MST) Date: Tue, 20 Jan 2009 08:04:10 -0800 From: John Fischer Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> Sender: John.Fischer@sun.com To: Mark Carlson Cc: LSARC-ext@sun.com, Srirama.Sharma@sun.com Reply-to: John.Fischer@sun.com Message-id: <1232467450.2056.2.camel@sr1-umpk-12> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> Status: RO Content-Length: 12320 Srirama, I am assuming, though the proposal does not state, that the port numbers are configurable. Is there any need to have 64-bit versions of the libraries? Thanks, John On Mon, 2009-01-19 at 22:01, Mark Carlson wrote: > I am sponsoring this familiarity case for Srirama Sharma, requesting > minor binding and timing out on 1/26/2009. > > -- mark > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Openwsman > 1.2. Name of Document Author/Supplier: > Author: Srirama Sharma > 1.3 Date of This Document: > 19 January, 2009 > > 2.0 Project Summary > 2.1 Project Description > > This project introduces the package of Openwsman 2.1.0 > into the SFW consolidation. > > > 4. Technical Description > > Openwsman is a project intended to provide an open-source implementation of the > Web Services Management specification (WS-Management) and to expose system management > information on the Linux operating system using the WS-Management protocol. > > WS-Management is based on a suite of web services specifications and usage requirements > that exposes a set of operations focused on and covers all system management aspects. > > > Command name Notes > ======================================== > openwsmand Openwsman daemon > > > 5. Interfaces > > 5.1 Exported Interfaces > > Interface Name Classification Comments > ------------------------------------------------------- --------------- --------------------------- > SUNWopenwsmanu Uncommitted Openwsman user package > SUNWopenwsmanr Uncommitted Openwsman root package > /usr/sbin/openwsmand Uncommitted Daemon > /usr/lib/libwsman.so.1.0.0 Uncommitted Shared library > /usr/lib/libwsman.so->libwsman.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman.so.1->libwsman.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_curl_client_transport.so.1.0.0 Uncommitted Shared library > /usr/lib/libwsman_curl_client_transport.so->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_curl_client_transport.so.1->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_client.so.1.0.0 Uncommitted Shared library > /usr/lib/libwsman_client.so->libwsman_client.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_client.so.1->libwsman_client.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_server.so.1.0.0 Uncommitted Shared library > /usr/lib/libwsman_server.so->libwsman_server.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_server.so.1->libwsman_server.so.1.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_clientpp.so.0.0.0 Uncommitted Shared library > /usr/lib/libwsman_clientpp.so->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link > /usr/lib/libwsman_clientpp.so.0->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link > /usr/lib/openwsman/ Uncommitted Dir where openwsman > libraries are installed > /usr/lib/openwsman/plugins Uncommitted Dir where plugins > are installed > /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1.0.0 Uncommitted Shared library > /usr/lib/openwsman/plugins/libwsman_identify_plugin.so->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link > /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link > /usr/lib/openwsman/plugins/libwsman_test.so.1.0.0 Uncommitted Shared library > /usr/lib/openwsman/plugins/libwsman_test.so->libwsman_test.so.1.0.0 Uncommitted Symbolic link > /usr/lib/openwsman/plugins/libwsman_test.so.1->libwsman_test.so.1.0.0 Uncommitted Symbolic link > /usr/lib/openwsman/authenticators Uncommitted Dir where authenticator > libraries are installed > /usr/lib/openwsman/authenticators/libwsman_file_auth.so.1.0.0 Uncommitted Shared library > /usr/lib/openwsman/authenticators/libwsman_pam_auth.so->libwsman_file_auth.so.1.0.0 Uncommitted Sy > mbolic link > /usr/lib/openwsman/authenticators/libwsman_pam_auth.so.1->libwsman_file_auth.so.1.0.0 Uncommitted Symbolic link > > /usr/lib/pkgconfig/openwsman-server.pc Uncommitted Pkgconfig file > /usr/lib/pkgconfig/openwsman++.pc Uncommitted Pkgconfig file > /usr/lib/pkgconfig/openwsman.pc Uncommitted Pkgconfig file > /usr/include/openwsman Uncommitted Dir where openwsman > headers are installed. > /usr/include/openwsman/wsman-types.h Uncommitted Header file > /usr/include/openwsman/wsman-names.h Uncommitted Header file > /usr/include/openwsman/wsman-debug.h Uncommitted Header file > /usr/include/openwsman/wsman-client.h Uncommitted Header file > /usr/include/openwsman/wsman-client-api.h Uncommitted Header file > /usr/include/openwsman/wsman-xml-api.h Uncommitted Header file > /usr/include/openwsman/wsman-client-transport.h Uncommitted Header file > /usr/include/openwsman/wsman-xml-serializer.h Uncommitted Header file > /usr/include/openwsman/wsman-xml-serialize.h Uncommitted Header file > /usr/include/openwsman/wsman-server-api.h Uncommitted Header file > /usr/include/openwsman/wsman-faults.h Uncommitted Header file > /usr/include/openwsman/wsman-soap-message.h Uncommitted Header file > /usr/include/openwsman/wsman-api.h Uncommitted Header file > /usr/include/openwsman/wsman-declarations.h Uncommitted Header file > /usr/include/openwsman/wsman-soap.h Uncommitted Header file > /usr/include/openwsman/wsman-epr.h Uncommitted Header file > /usr/include/openwsman/wsman-filter.h Uncommitted Header file > /usr/include/openwsman/wsman-soap-envelope.h Uncommitted Header file > /usr/include/openwsman/wsman-subscription-repository.h Uncommitted Header file > /usr/include/openwsman/wsman-event-pool.h Uncommitted Header file > /usr/include/openwsman/wsman-cimindication-processor.h Uncommitted Header file > /usr/include/openwsman/u/buf.h Uncommitted Header file > /usr/include/openwsman/u/carpal.h Uncommitted Header file > /usr/include/openwsman/u/libu.h Uncommitted Header file > /usr/include/openwsman/u/log.h Uncommitted Header file > /usr/include/openwsman/u/logprv.h Uncommitted Header file > /usr/include/openwsman/u/memory.h Uncommitted Header file > /usr/include/openwsman/u/misc.h Uncommitted Header file > /usr/include/openwsman/u/os.h Uncommitted Header file > /usr/include/openwsman/u/uri.h Uncommitted Header file > /usr/include/openwsman/u/uuid.h Uncommitted Header file > /usr/include/openwsman/u/lock.h Uncommitted Header file > /usr/include/openwsman/u/strings.h Uncommitted Header file > /usr/include/openwsman/u/md5.h Uncommitted Header file > /usr/include/openwsman/u/list.h Uncommitted Header file > /usr/include/openwsman/u/hash.h Uncommitted Header file > /usr/include/openwsman/u/base64.h Uncommitted Header file > /usr/include/openwsman/u/iniparser.h Uncommitted Header file > /usr/include/openwsman/u/debug.h Uncommitted Header file > /usr/include/openwsman/u/uerr.h Uncommitted Header file > /usr/include/openwsman/u/uoption.h Uncommitted Header file > /usr/include/openwsman/u/gettimeofday.h Uncommitted Header file > /usr/include/openwsman/u/syslog.h Uncommitted Header file > /usr/include/openwsman/u/pthreadx.h Uncommitted Header file > /usr/include/openwsman/cim/cim-interface.h Uncommitted Header file > /usr/include/openwsman/cpp/OpenWsmanClient.h Uncommitted Header file > /usr/include/openwsman/cpp/Exception.h Uncommitted Header file > /usr/include/openwsman/cpp/WsmanClient.h Uncommitted Header file > /usr/include/openwsman/cpp/WsmanEPR.h Uncommitted Header file > /usr/include/openwsman/cpp/WsmanFilter.h Uncommitted Header file > /usr/share/man/man8/openwsmand.8 Uncommitted Manpage > /etc/openwsman Uncommitted Dir where openwsman config > files are installed > /etc/openwsman/owsmangencert.sh Uncommitted Script > /etc/openwsman/openwsman.conf Uncommitted Config file > /etc/openwsman/ssleay.cnf Uncommitted Config file > /var/svc/manifest/network/openwsmasnd.xml Uncommitted SVC Manifest file > /lib/svc/method/svc-openwsmand Uncommitted SVC Method file > Ports 8889 and 8888 Uncommitted Recommended ports for > WS-Management > > > 5.2. Imported Interfaces > > Interface Name Classification Comments > --------------------------- ---------------- --------------------------------- > /usr/lib/libcurl.so.3 Uncommitted library provided by SUNWcurl pkg > /usr/lib/libgss.so.1 Uncommitted library provided by SUNWgss > /usr/lib/libidn.so.11 Uncommitted library provided by SUNWgnu-idn > /lib/libz.so.1 Uncommitted library provided by SUNWzlibr > /lib/libcrypto.so.0.9.8 Uncommitted library provided by SUNWopenssl-libraries > /lib/libssl.so.0.9.8 Uncommitted library provided by SUNWopenssl-libraries > /lib/libxml2.so.2 Uncommitted library provided by SUNWlxmlr > Ports 5988/5989 Uncommitted Port through which the daemon connects to > cimserver through CIM-XML. > > > > 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 gww@eng.sun.com Tue Jan 20 22:26:30 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0L6QUFX004213 for ; Tue, 20 Jan 2009 22:26:30 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0L6QTB9018682 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 20 Jan 2009 22:26:30 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDT00C095W5CD00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 20 Jan 2009 23:26:29 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDT00AAB5W50M10@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 20 Jan 2009 23:26:29 -0700 (MST) 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 n0L6QQNI033896; Tue, 20 Jan 2009 22:26:26 -0800 (PST) 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 n0L6PRRI002180; Tue, 20 Jan 2009 22:25:27 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n0L6PRvA002179; Tue, 20 Jan 2009 22:25:27 -0800 (PST) Date: Tue, 20 Jan 2009 22:25:27 -0800 (PST) From: Gary Winiger Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] To: LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com Cc: Srirama.Sharma@sun.com Message-id: <200901210625.n0L6PRvA002179@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2578 > 2.0 Project Summary > 2.1 Project Description > > This project introduces the package of Openwsman 2.1.0 > into the SFW consolidation. I'm confused here about a number of things. * Is this a service and therefore needing to be controlled by SMF? I see what looks like a possible mention of a service manifest, but no mention of an FMRI, method context, administrative authorizations, Rights Profiles, properties such as local_only, .... I'd expect the man page to discuss at least the FMRI, Rights Profiles and properties. * The man page states: "openwsmand service can be started only by a privileged user." In the light of Solaris Privileges, SMF and RBAC what does this mean? * The Check List says this project uses PAM and the man page shows: /etc/pam.d/openwsman: #%PAM-1.0 auth required pam_unix2.so nullok auth required pam_nologin.so account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_unix2.so none None of these PAM modules seem to be delivered by this project and are otherwise not part of OpenSolaris. Furthermore, the imported interfaces do not show libpam. * The imported interfaces appear to show the use of OpenSSL. IIRC, it's use is contracted. I don't find a mention of the contract. * This project appears to do authentication, yet I don't see mention of how that authentication is audited or a discussion why it shouldn't be. The reference for the Check List auditing section seems to say to me if the project does authentication, it audits that authentication. * The Check List says: "The openwsman daemon is sufficiently privileged to authenticate the wsman client. There will be no request for a password change coming in over the wire via WS-Man." With Solaris Privileges, what does "sufficiently privileged ..." mean? If there is no password change over the wire, how exactly are passwords managed? htpasswd/htdigest do not appear to be part the imported interfaces. * The Check List says: "If the openwsman daemon is configured to use PAM, then the service configuration file provided by the administrator in /etc/pam.d will be used." Is PAM configured? See above about the use of PAM. * What is the analysis of the security implications of this project vis-a-vis currently delivered Sun SNMP? Other than viewing/reporting, what type of administrative file/database modifications/changes does this project permit? Gary.. From Srirama.Sharma@sun.com Thu Jan 22 06:41:19 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0MEfJKL004462 for ; Thu, 22 Jan 2009 06:41:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0MEfCAj008716 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 14:41:18 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDV0000ZNGTBD00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 22 Jan 2009 07:41:17 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDV00FUQNGSJJ30@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 22 Jan 2009 07:41:16 -0700 (MST) 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 n0MEfGI7017290 for ; Thu, 22 Jan 2009 14:41:16 +0000 (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 <0KDV00E01MUS9V00@mail-amer.sun.com> (original mail from Srirama.Sharma@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 22 Jan 2009 07:41:16 -0700 (MST) Received: from [10.114.58.72] ([203.91.196.62]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDV00L8MNGAYG60@mail-amer.sun.com>; Thu, 22 Jan 2009 07:41:01 -0700 (MST) Date: Thu, 22 Jan 2009 20:08:57 +0530 From: Srirama Sharma Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <20090120154512.GA22307@ferpo.Central.Sun.COM> Sender: Srirama.Sharma@sun.com To: Peter Schow Cc: Mark Carlson , LSARC-ext@sun.com, Srirama Sharma Message-id: <49788501.3060005@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xss9XeP0yfQkyqJg5TaMNw)" X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> <20090120154512.GA22307@ferpo.Central.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070604) Status: RO Content-Length: 4835 This is a multi-part message in MIME format. --Boundary_(ID_xss9XeP0yfQkyqJg5TaMNw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Peter, Thanks for your comments. Please see response in line. Peter Schow said the following on Tuesday 20 January 2009 09:15 PM: > On Mon, Jan 19, 2009 at 10:01:22PM -0800, Mark Carlson wrote: > >> 4. Technical Description >> >> Openwsman is a project intended to provide an open-source implementation of the >> Web Services Management specification (WS-Management) and to expose system management >> information on the Linux operating system using the WS-Management protocol. >> >> WS-Management is based on a suite of web services specifications and usage requirements >> that exposes a set of operations focused on and covers all system management aspects. >> > > 1. It would be nice to see the small openwsman CLI (wsman) bundled into > SUNWopenwsmanu as well. I've found it to be invaluable for openwsman > testing and verification purposes. > This would be a separate case we will have to schedule as a follow-on. > 2. The description says that openwsman will expose system instrumentation > on Linux. What will it do on Solaris? Openwsman does the same even on Solaris. Have modified the description as below to make it more generic. "Openwsman is a project intended to provide an open-source implementation of the Web Services Management specification (WS-Management) and to expose system management information on the underlying operating system using the WS-Management protocol." > Is a CIM server forthcoming in a later case? > OpenPegasus CIM server has already been integrated into Solaris as part of LSARC/2008/040 > 3. The openwsman library generates and uses UUIDs; you'll probably want > to include libuuid in your imports. > Done. Have added and will be sending out the modified ARC docs once all changes are incorporated. Thanks, Srirama --Boundary_(ID_xss9XeP0yfQkyqJg5TaMNw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Peter,

Thanks for your comments. Please see response in line.

Peter Schow said the following on Tuesday 20 January 2009 09:15 PM: 
On Mon, Jan 19, 2009 at 10:01:22PM -0800, Mark Carlson wrote:
  
4. Technical Description
 
      Openwsman is a project intended to provide an open-source implementation of the
      Web Services Management specification (WS-Management) and to expose system management
      information on the Linux operating system using the WS-Management protocol.

      WS-Management is based on a suite of web services specifications and usage requirements
      that exposes a set of operations focused on and covers all system management aspects.
    

1. It would be nice to see the small openwsman CLI (wsman) bundled into
   SUNWopenwsmanu as well.  I've found it to be invaluable for openwsman
   testing and verification purposes.

This would be a separate case we will have to schedule as a follow-on.

2. The description says that openwsman will expose system instrumentation
   on Linux.  What will it do on Solaris?

Openwsman does the same even on Solaris. Have modified the description as below to make it more generic.

"Openwsman is a project intended to provide an open-source implementation of the
Web Services Management specification (WS-Management) and to expose system management
information on the underlying operating system using the WS-Management protocol."

Is a CIM server forthcoming in a later case?

OpenPegasus CIM server has already been integrated into Solaris as part of LSARC/2008/040

3. The openwsman library generates and uses UUIDs; you'll probably want
   to include libuuid in your imports.
Done. Have added and will be sending out the modified ARC docs once all changes are incorporated.

Thanks,
Srirama

--Boundary_(ID_xss9XeP0yfQkyqJg5TaMNw)-- From Srirama.Sharma@sun.com Thu Jan 22 06:42:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0MEgs7r004522 for ; Thu, 22 Jan 2009 06:42:54 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0MEgpds013052 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 06:42:54 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDV00003NJIH400@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Thu, 22 Jan 2009 07:42:54 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDV00FZ0NJIJJ30@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Thu, 22 Jan 2009 07:42:54 -0700 (MST) 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 n0MEgsZR018131 for ; Thu, 22 Jan 2009 14:42:54 +0000 (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 <0KDV00301MJIAO00@mail-amer.sun.com> (original mail from Srirama.Sharma@Sun.COM) for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Thu, 22 Jan 2009 07:42:54 -0700 (MST) Received: from [10.114.58.72] ([203.91.196.62]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDV00629NIKXW50@mail-amer.sun.com>; Thu, 22 Jan 2009 07:42:23 -0700 (MST) Date: Thu, 22 Jan 2009 20:10:19 +0530 From: Srirama Sharma Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <1232467450.2056.2.camel@sr1-umpk-12> Sender: Srirama.Sharma@sun.com To: John.Fischer@sun.com Cc: Mark Carlson , LSARC-ext@sun.com, Srirama Sharma Message-id: <49788553.3040909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> <1232467450.2056.2.camel@sr1-umpk-12> User-Agent: Thunderbird 2.0.0.4 (X11/20070604) Status: RO Content-Length: 557 Hi John, Please see comments inline. John Fischer said the following on Tuesday 20 January 2009 09:34 PM: > Srirama, > > I am assuming, though the proposal does not state, > that the port numbers are configurable. > Yes, the recommended ports are 8889 and 8888. However these can be configured in "/etc/openwsman/openwsman.conf". An example entry of the server configuration is specified in the man page. > Is there any need to have 64-bit versions of the libraries? > We do ship 64 bit version of the daemon and the libraries. Thanks, Srirama From Srirama.Sharma@Sun.COM Thu Jan 22 06:52:59 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0MEqx5K004670 for ; Thu, 22 Jan 2009 06:52:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0MEqx7f018670 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 06:52:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDV00903O0BCO00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 06:52:59 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDV001ATO0APU80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 06:52:58 -0800 (PST) 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 n0MEqvPR023583 for ; Thu, 22 Jan 2009 14:52:57 +0000 (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 <0KDV00301MJIAO00@mail-amer.sun.com> (original mail from Srirama.Sharma@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 07:52:56 -0700 (MST) Received: from [10.114.58.72] ([203.91.196.62]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDV0048LNZ7HHD0@mail-amer.sun.com>; Thu, 22 Jan 2009 07:52:24 -0700 (MST) Date: Thu, 22 Jan 2009 20:20:19 +0530 From: Srirama Sharma Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <200901210625.n0L6PRvA002179@marduk.eng.sun.com> Sender: Srirama.Sharma@Sun.COM To: Gary Winiger Cc: LSARC-ext@Sun.COM, markcarl@sac.sfbay.sun.com, Srirama Sharma Message-id: <497887AB.3020508@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Z8ulSN7+m8SJHbBPvP9b7g)" X-PMX-Version: 5.4.1.325704 References: <200901210625.n0L6PRvA002179@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070604) Status: RO Content-Length: 57357 This is a multi-part message in MIME format. --Boundary_(ID_Z8ulSN7+m8SJHbBPvP9b7g) Content-type: multipart/alternative; boundary="Boundary_(ID_XXf4nbPNxyIAizrqMCKUJQ)" --Boundary_(ID_XXf4nbPNxyIAizrqMCKUJQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary, Thanks for the comments. Please see response in lined for most of the queries except one. Will revert back on that soon. Also have attached the modified ARC one pager and the FOSS checklist. Gary Winiger said the following on Wednesday 21 January 2009 11:55 AM: >> 2.0 Project Summary >> 2.1 Project Description >> >> This project introduces the package of Openwsman 2.1.0 >> into the SFW consolidation. >> > > I'm confused here about a number of things. > > * Is this a service and therefore needing to be controlled by SMF? Yes. Openwsmand is a daemon and hence needs to be controlled by SMF > I see what looks like a possible mention of a service manifest, but no mention > of an FMRI, method context, administrative authorizations, Rights Profiles, > properties such as local_only, .... I'd expect the man page to discuss at > least the FMRI, Rights Profiles and properties. > This service is manged under the FMRI "svc:/network/openwsmand" No specific Rights Profiles are getting added to "/etc/security/prof_attr". Instead, below "method_context" is defined in the manifest file for all the methods i.e start, stop and refresh. Could you please confirm if below text is sufficient under the NOTES section of the man page: "openwsmand service is by default disabled and it is managed by the service management facility, smf(5), under the service identifier: svc:/network/openwsmand Administrative actions on this service, such as enabling, disabling, or refreshing, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command" > * The man page states: "openwsmand service can be started only by > a privileged user." In the light of Solaris Privileges, SMF and RBAC > what does this mean? > Administrative actions on this service, such as enabling, disabling, or refreshing, can be performed using svcadm(1M). All these methods (start, stop and refresh) have below method context. So no new RBAC profile has been added. > * The Check List says this project uses PAM and the man page shows: > /etc/pam.d/openwsman: > > #%PAM-1.0 > auth required pam_unix2.so nullok > auth required pam_nologin.so > account required pam_unix2.so > password required pam_pwcheck.so nullok > password required pam_unix2.so nullok use_first_pass use_authtok > session required pam_unix2.so none > > None of these PAM modules seem to be delivered by this project and > are otherwise not part of OpenSolaris. Yes. The openwsman daemon can be configured to use PAM for authentication. By default, it only uses file based authentication where in password files generated using htpasswd/htdigest are used. The man page only shows a template pam.conf (the one which was available with the community source tarball). The pam.conf is currently not getting shipped as part of this package. The administrator has to create appropriate pam.conf in which the pam modules already delivered with OpenSolaris or any site specifc pam module could be made use of. Please advice if man page needs to be modified to show an example which makes use of generic pam modules which are part of OpenSolaris. > Furthermore, the imported interfaces do not show libpam. > Done. Have added libpam entry into the imported interface table with stability "committed". Is the stability correct ? > * The imported interfaces appear to show the use of OpenSSL. IIRC, > it's use is contracted. I don't find a mention of the contract. > Will check with Mark on the status and revert back. > * This project appears to do authentication, yet I don't see mention > of how that authentication is audited or a discussion why it shouldn't be. > The reference for the Check List auditing section seems to say to me if the > project does authentication, it audits that authentication. > > openwsman daemon has a command line option to enable syslog and set the verbosity of the syslog output. Also, here the users who are getting authenticated by openwsmand are not Solaris users. These are the users created using htpasswd/htdigest with OPENWSMAN realm by default. But when it is configured to use PAM, it could make use of /etc/paswd and /etc/shadow to check the credentials of the user. So is Solaris auditing required in this case ? > * The Check List says: "The openwsman daemon is sufficiently privileged > to authenticate the wsman client. There will be no request for a password > change coming in over the wire via WS-Man." With Solaris Privileges, what > does "sufficiently privileged ..." mean? As specified in the method_context in the manifest file, the daemon will be started with uid and gid as root and with basic privileges. > If there is no password change over the wire, how exactly are passwords managed? The administrator will have to use htpasswd/htdigest to recreate the new password and install the same into the current simple/digest password files (default located in /etc/openwsman dir) . > htpasswd/htdigest do not appear to be part the imported interfaces. > Done. Have added both of them in to the imported interface table. > * The Check List says: "If the openwsman daemon is configured to use > PAM, then the service configuration file provided by the administrator in > /etc/pam.d will be used." Is PAM configured? See above about the use > of PAM. > This project provides an option to the administrator to configure openwsman daemon to make use PAM authentication. This can be done in the openwsman configuration file "/etc/openwsman/openwsman.conf". But by default, it makes use of file based authentication only. Based on the type of authentication which is configured, openwsman daemon loads either "libwsman_file_auth.so.1.0.0"or "libwsman_pam_auth.so.1.0.0" In case of file based authentication which is default, the password files generated using htpasswd/htdigest will be looked for checking if the user name and password provided through the wsman client is valid. When Openwsman daemon is configured to use PAM for authentication, openwsman pam plugin library in turn links to libpam and makes use of function calls like pam_start(), pam_authenticate() and pam_stop () to authenticate the user. Thanks, Srirama --Boundary_(ID_XXf4nbPNxyIAizrqMCKUJQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary,

Thanks for the comments. Please see response in lined for most of the queries except one. Will revert back on that soon.

Also have attached the modified ARC one pager and the FOSS checklist.


Gary Winiger said the following on Wednesday 21 January 2009 11:55 AM: 
2.0 Project Summary
    2.1 Project Description

	This project introduces the package of Openwsman 2.1.0
	into the SFW consolidation.
    

	I'm confused here about a number of things.
	
	* Is this a service and therefore needing to be controlled by SMF?

Yes. Openwsmand is a daemon and hence needs to be controlled by SMF

I see what looks like a possible  mention of a service manifest, but no mention
of an FMRI, method context, administrative authorizations, Rights Profiles,
properties such as local_only, ....  I'd expect the man page to discuss at
least the FMRI, Rights Profiles and properties.

This service is manged under the FMRI "svc:/network/openwsmand"

No specific Rights Profiles are getting added to "/etc/security/prof_attr". Instead, below "method_context" is defined in the manifest file for all the methods i.e start, stop and refresh.

                <method_context>
                        <method_credential
                        user='root'
                        group='root'
                        privileges='basic'
                        />
                </method_context>

Could you please confirm if below text is sufficient under the NOTES section of the man page:

"openwsmand service is by default disabled and it is managed by the service management facility, smf(5), under the service identifier:

svc:/network/openwsmand

Administrative actions on this service,  such  as  enabling, disabling,  or  refreshing,  can be performed using svcadm(1M).
The service's status can be  queried  using  the svcs(1) command"


	* The man page states: "openwsmand service can be started only by
a privileged user."  In the light of Solaris Privileges, SMF and RBAC
what does this mean?

Administrative actions on this service,  such  as  enabling, disabling,  or  refreshing,  can be performed using svcadm(1M).

All these methods (start, stop and refresh) have below method context. So no new RBAC profile has been added.

                <method_context>
                        <method_credential
                        user='root'
                        group='root'
                        privileges='basic'
                        />
                </method_context>

	* The Check List says this project uses PAM and the man page shows:
	  /etc/pam.d/openwsman:

	  #%PAM-1.0
	  auth       required     pam_unix2.so    nullok
	  auth       required     pam_nologin.so
	  account    required     pam_unix2.so
	  password   required     pam_pwcheck.so  nullok
	  password   required     pam_unix2.so    nullok use_first_pass use_authtok
	  session    required     pam_unix2.so    none

	  None of these PAM modules seem to be delivered by this project and
are otherwise not part of OpenSolaris.

Yes. The openwsman daemon can be configured to use PAM for authentication. By default, it only uses file based  authentication where in password files generated using htpasswd/htdigest are used.

The man page only shows a template pam.conf (the one which was available with the community source tarball). The pam.conf is currently not getting shipped as part of this package. The administrator has to create appropriate pam.conf in which the pam modules already delivered with OpenSolaris or any site specifc pam module could be made use of.

Please advice if man page needs to be modified to show an example which makes use of generic pam modules which are part of OpenSolaris.


 Furthermore, the imported interfaces do not show libpam.
Done. Have added libpam entry into the imported interface table with stability "committed".  Is the stability correct ? 

	* The imported interfaces appear to show the use of OpenSSL.  IIRC,
it's use is contracted.  I don't find a mention of the contract.

Will check with Mark on the status and revert back.

	* This project appears to do authentication, yet I don't see mention
of how that authentication is audited or a discussion why it shouldn't be.
The reference for the Check List auditing section seems to say to me if the
project does authentication, it audits that authentication.
openwsman daemon has a command line option to enable syslog and set the verbosity of the syslog output.

Also, here the users who are getting authenticated by openwsmand are not Solaris users. These are the users created using htpasswd/htdigest with OPENWSMAN realm by default.  But when it is configured to use PAM, it could make use of /etc/paswd and /etc/shadow to check the credentials of the user. So is Solaris auditing required in this case ? 


	* The Check List says: "The openwsman daemon is sufficiently privileged
to authenticate the wsman client.  There will be no request for a password
change coming in over the wire via WS-Man." With Solaris Privileges, what
does "sufficiently privileged ..." mean?

As specified in the method_context in the manifest file, the daemon will be started with uid and gid as root and with basic privileges.

 If there is no password change over the wire, how exactly are passwords managed?

The administrator will have to use htpasswd/htdigest to recreate the new password and install the same into the current simple/digest password files (default located in /etc/openwsman dir) .

 htpasswd/htdigest do not appear to be part the imported interfaces.

Done. Have added both of them in to the imported interface table.


	* The Check List says: "If the openwsman daemon is configured to use
PAM, then the service configuration file provided by the administrator in
/etc/pam.d will be used."  Is PAM configured?  See above about the use
of PAM.

This project provides an option to the administrator to configure openwsman daemon to make use PAM authentication.  This can be done in the openwsman configuration file "/etc/openwsman/openwsman.conf". But by default, it makes use of file based authentication only.

Based on the type of authentication which is configured, openwsman daemon loads either "libwsman_file_auth.so.1.0.0"or "libwsman_pam_auth.so.1.0.0"

In case of file based authentication which is default, the password files generated using htpasswd/htdigest will be looked for checking if the user name and password provided through the wsman client is valid.

When Openwsman daemon is configured to use PAM for authentication, openwsman pam plugin library in turn links to libpam  and makes use of function calls like pam_start(),  pam_authenticate() and pam_stop () to authenticate the user.


Thanks,
Srirama
--Boundary_(ID_XXf4nbPNxyIAizrqMCKUJQ)-- --Boundary_(ID_Z8ulSN7+m8SJHbBPvP9b7g) Content-type: text/plain; name=Openwsman-ARC-FOSS-Checklist.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=Openwsman-ARC-FOSS-Checklist.txt FCL--FOSS Check List 0. Introduction 0.1 Document History Version Author Changes Date 0.1 Srirama Sharma Initial Draft 01/06/2009 0.2 Purpose This checklist is to aid in the FastTrack ARC review process for the integration of Openwsman project into OpenSolaris. 1.0 Project Information 1.1 Name of project/component Openwsman 1.2 Author of document Srirama Sharma (srirama.sharma@sun.com) 2.0 Project Summary 2.1 Project Description Openwsman is a project intended to provide an open-source implementation of the Web Services Management specification (WS-Management) and to expose system management information on the underlying operating system using the WS-Management protocol. WS-Management is based on a suite of web services specifications and usage requirements that exposes a set of operations focused on and covers all system management aspects. 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [X] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Type of project Is this case a Linux Familiarity project? [X] Yes [ ] No 2.4 Originating Community 2.4.1 Community Name http://www.openwsman.org/project/openwsman 2.4.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [X] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [X] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [X] No 3.0 Technical Description 3.1 Installation & Sharable 3.1.1S Solaris Installation - section only required for Solaris Software (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [X] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [X] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [X] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [X] No or N/A Do any of the components of this project conflict with anything under /usr? (see http://opensolaris.org/os/community/arc/caselog/2007/047/ for details) [ ] Yes - explain below [X] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [X] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [X] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) Does this project install software into a :\Program Files\Sun\ or :\Sun\ directory? [ ] Yes [ ] No - ARC review required Does the project use the Windows registry? [ ] Yes [ ] No - ARC review required Does the project use HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ for the registry key? [ ] Yes [ ] No - ARC review required Is the project's stored location HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? [ ] Yes [ ] No - ARC review required 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [X] No If yes are these components packaged to be shared with the other FOSS? [ ] Yes [ ] No - ARC review required [X] N/A Are these components already in the Solaris WOS? [ ] Yes [X] No - continue with next section (section 3.2) If yes are these newer versions being delivered? [ ] Yes [ ] No - ARC review required If yes are the newer versions replacing the existing versions? [ ] Yes [ ] No - ARC review required 3.2 Exported Libraries Are libraries being delivered by this project? [X] Yes [ ] No - continue with next section (section 3.3) Are 64-bit versions of the libraries being delivered? [X] Yes [ ] No - ARC review required Are static versions of the libraries being delivered? [ ] Yes - ARC review required [X] No 3.3 Services and the /etc Directory (see http://opensolaris.org/os/community/arc/policies/SMF-policy/) Does the project integrate anything into /etc/init.d or /etc/rc?.d? [ ] Yes - ARC review required [X] No Does the project integrate any new entries into /etc/inittab or /etc/inetd.conf? [ ] Yes - ARC review required [X] No Does the project integrate any private non-public files into /etc/default or /etc/ configuration files? [ ] Yes - ARC review required [X] No Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [X] No 3.4 Security 3.4.1 Secure By Default (see http://opensolaris.org/os/community/arc/policies/secure-by-default/ for details) (see http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ for details) (see parts of http://opensolaris.org/os/community/arc/policies/SMF-policy/ for addtional details) Are there any network services provided by this project? [X] Yes [ ] No - continue with the next section (section 3.4.2) Are network services enabled by default? [ ] Yes - ARC review required [X] No [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [X] No [ ] N/A Are inbound network communications denied by default? [X] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [X] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [X] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [X] Yes [ ] No - ARC review required [ ] N/A 3.4.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes - ARC review required [X] No - continue with next section (section 3.4.3) If yes then are the setuid/setgid privileges handled by the use of roles? [ ] Yes [ ] No - ARC review required 3.4.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Does this component contain administrative or security enforcing software? [ ] Yes - ARC review required [X] No - continue to next section (section 3.4.4) (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes - ARC contract and Audit project team review required [ ] No - ARC review required 3.4.4 Authentication (see http://opensolaris.org/os/community/arc/policies/PAM/) Do the components contain any authentication code? [X] Yes [ ] No - continue to next section (section 3.4.5) If yes do the components use PAM (plugable authentication modules) for authentication? [X] Yes [ ] No - ARC review required If yes is a single PAM session maintained during authentication? [X] Yes [ ] No - ARC review required If yes are the components sufficiently privileged to allow the requested operations (authentication, password change, process credential manipulation, audit state initialization)? [X] Yes - briefly describe below [ ] No - ARC review required The openwsman daemon is sufficiently privileged to authenticate the wsman client. There will be no request for a password change coming in over the wire via WS-Man. 3.4.5 Passwords (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details) Do any of the components for the project deal with passwords? [X] Yes [ ] No - continue to next section (section 3.4.6) If yes are these passwords entered via the CLI or environment? [ ] Yes - ARC review required [X] No Are passwords stored within the file system for the component? [X] Yes [ ] No - continue to next section (section 3.4.6) If yes are the permissions on the file such to protect exposing the password(s)? [X] Yes [ ] No - ARC review required 3.4.6 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Are there any network protocols used by this project? [X] Yes [ ] No - continue with the next section (section 3.5) Do the components use standard network protocols? [X] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [X] Yes - explain below [ ] No [ ] N/A The communication between the client and the server happens over http/https protocol. The WS-Management daemon does authenticate the user credentials before servicing any operation contracts (Eg:identify, pull, etc.. ) requested by the client. Do the components make use of secret information during authentication and/or authorization? [X] Yes - explain below [ ] No [ ] N/A The openwsman daemon authenticates its WS-Man based clients based on the kind of authenticator plugin specified while configuring it. If it is simple or digest authentication, then the corresponding files generated using htpasswd/htdigest would be used. These files are default located in /etc/openwsman dir. However the administrator can modify it in /etc/openwsman/openwsman.conf. If the openwsman daemon is configured to use PAM, then the service configuration file provided by the administrator in /etc/pam.d will be used. 3.5 Networking Do the components access the network? [X] Yes [ ] No - continue with the next section (section 3.6) If yes do the components support IPv6? [X] Yes [ ] No - ARC review required 3.6 Core Solaris Components Do the components of this project compete with or duplicate core Solaris components? [ ] Yes - ARC review required [X] No Examples of Core Solaris Components include but are not limited to: Secure By Default Authorizations PAM -- Plugable Authentication Module Privilege PRM -- Process Rights Management -- Privilege Audit xVm -- Virtualization zones / Solaris Containers PRM -- Process Rights Management RBAC -- Role Based Access Control TX / Trusted Extensions ZFS SMF -- Service Management Facility FMA -- Fault Management Architecture SCF -- Smart Card Facility IPsec 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments ------------------------------------------------------- --------------- --------------------------- SUNWopenwsmanu Uncommitted Openwsman user package SUNWopenwsmanr Uncommitted Openwsman root package /usr/sbin/openwsmand Uncommitted Daemon /usr/lib/libwsman.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman.so->libwsman.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman.so.1->libwsman.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_curl_client_transport.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_curl_client_transport.so->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_curl_client_transport.so.1->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_client.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_client.so->libwsman_client.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_client.so.1->libwsman_client.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_server.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_server.so->libwsman_server.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_server.so.1->libwsman_server.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_clientpp.so.0.0.0 Uncommitted Shared library /usr/lib/libwsman_clientpp.so->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link /usr/lib/libwsman_clientpp.so.0->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link /usr/lib/openwsman/ Uncommitted Dir where openwsman libraries are installed /usr/lib/openwsman/plugins Uncommitted Dir where plugins are installed /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/plugins/libwsman_identify_plugin.so->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_test.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/plugins/libwsman_test.so->libwsman_test.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_test.so.1->libwsman_test.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/authenticators Uncommitted Dir where authenticator libraries are installed /usr/lib/openwsman/authenticators/libwsman_file_auth.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/authenticators/libwsman_pam_auth.so->libwsman_file_auth.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/authenticators/libwsman_pam_auth.so.1->libwsman_file_auth.so.1.0.0 Uncommitted Symbolic link /usr/lib/pkgconfig/openwsman-server.pc Uncommitted Pkgconfig file /usr/lib/pkgconfig/openwsman++.pc Uncommitted Pkgconfig file /usr/lib/pkgconfig/openwsman.pc Uncommitted Pkgconfig file /usr/include/openwsman Uncommitted Dir where openwsman headers are installed. /usr/include/openwsman/wsman-types.h Uncommitted Header file /usr/include/openwsman/wsman-names.h Uncommitted Header file /usr/include/openwsman/wsman-debug.h Uncommitted Header file /usr/include/openwsman/wsman-client.h Uncommitted Header file /usr/include/openwsman/wsman-client-api.h Uncommitted Header file /usr/include/openwsman/wsman-xml-api.h Uncommitted Header file /usr/include/openwsman/wsman-client-transport.h Uncommitted Header file /usr/include/openwsman/wsman-xml-serializer.h Uncommitted Header file /usr/include/openwsman/wsman-xml-serialize.h Uncommitted Header file /usr/include/openwsman/wsman-server-api.h Uncommitted Header file /usr/include/openwsman/wsman-faults.h Uncommitted Header file /usr/include/openwsman/wsman-soap-message.h Uncommitted Header file /usr/include/openwsman/wsman-api.h Uncommitted Header file /usr/include/openwsman/wsman-declarations.h Uncommitted Header file /usr/include/openwsman/wsman-soap.h Uncommitted Header file /usr/include/openwsman/wsman-epr.h Uncommitted Header file /usr/include/openwsman/wsman-filter.h Uncommitted Header file /usr/include/openwsman/wsman-soap-envelope.h Uncommitted Header file /usr/include/openwsman/wsman-subscription-repository.h Uncommitted Header file /usr/include/openwsman/wsman-event-pool.h Uncommitted Header file /usr/include/openwsman/wsman-cimindication-processor.h Uncommitted Header file /usr/include/openwsman/u/buf.h Uncommitted Header file /usr/include/openwsman/u/carpal.h Uncommitted Header file /usr/include/openwsman/u/libu.h Uncommitted Header file /usr/include/openwsman/u/log.h Uncommitted Header file /usr/include/openwsman/u/logprv.h Uncommitted Header file /usr/include/openwsman/u/memory.h Uncommitted Header file /usr/include/openwsman/u/misc.h Uncommitted Header file /usr/include/openwsman/u/os.h Uncommitted Header file /usr/include/openwsman/u/uri.h Uncommitted Header file /usr/include/openwsman/u/uuid.h Uncommitted Header file /usr/include/openwsman/u/lock.h Uncommitted Header file /usr/include/openwsman/u/strings.h Uncommitted Header file /usr/include/openwsman/u/md5.h Uncommitted Header file /usr/include/openwsman/u/list.h Uncommitted Header file /usr/include/openwsman/u/hash.h Uncommitted Header file /usr/include/openwsman/u/base64.h Uncommitted Header file /usr/include/openwsman/u/iniparser.h Uncommitted Header file /usr/include/openwsman/u/debug.h Uncommitted Header file /usr/include/openwsman/u/uerr.h Uncommitted Header file /usr/include/openwsman/u/uoption.h Uncommitted Header file /usr/include/openwsman/u/gettimeofday.h Uncommitted Header file /usr/include/openwsman/u/syslog.h Uncommitted Header file /usr/include/openwsman/u/pthreadx.h Uncommitted Header file /usr/include/openwsman/cim/cim-interface.h Uncommitted Header file /usr/include/openwsman/cpp/OpenWsmanClient.h Uncommitted Header file /usr/include/openwsman/cpp/Exception.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanClient.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanEPR.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanFilter.h Uncommitted Header file /usr/share/man/man8/openwsmand.8 Uncommitted Manpage /etc/openwsman Uncommitted Dir where openwsman config files are installed /etc/openwsman/owsmangencert.sh Uncommitted Script /etc/openwsman/openwsman.conf Uncommitted Config file /etc/openwsman/ssleay.cnf Uncommitted Config file /var/svc/manifest/network/openwsmasnd.xml Uncommitted SVC Manifest file /lib/svc/method/svc-openwsmand Uncommitted SVC Method file Ports 8889 and 8888 Uncommitted Recommended ports for WS-Management 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- ---------------- --------------------------------- /usr/lib/libcurl.so.3 Uncommitted library provided by SUNWcurl pkg /usr/lib/libgss.so.1 Uncommitted library provided by SUNWgss pkg /usr/lib/libidn.so.11 Uncommitted library provided by SUNWgnu-idn pkg /lib/libz.so.1 Uncommitted library provided by SUNWzlibr pkg /lib/libcrypto.so.0.9.8 Uncommitted library provided by SUNWopensslr pkg /lib/libssl.so.0.9.8 Uncommitted library provided by SUNWopensslr pkg /lib/libxml2.so.2 Uncommitted library provided by SUNWlxmlr pkg Ports 5988/5989 Uncommitted Port through which the daemon connects to cimserver through CIM-XML. /lib/libuuid.so.1 Committed library provided by SUNWcslr pkg /lib/libpam.so.1 Committed library provided by SUNWcslr pkg /usr/bin/htpasswd Uncommitted Binary used to generate basic password file /usr/bin/htdigest Uncommitted Binary used to generate digest password file Brief Interface Classifications - See Appendix C for definitions Volatile - interfaces are fluid and will follow a rapidly changing community Uncommitted - interfaces are still evolving in the community and might follow the community Committed - interfaces are stable in the community Project Private - no review required, just document in table Contracted (interface modifier) - further review required Appendix A - References 1. Solaris Installation Locations Policy http://opensolaris.org/os/community/arc/policies/install-locations/ 2. /usr/gnu Installation ARC case http://opensolaris.org/os/community/arc/caselog/2007/047/ 3. Secure By Default Policy http://opensolaris.org/os/community/arc/policies/secure-by-default/ 4. Network Install Time Securityuy Policy http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ 5. Adding RBAC Authorizations Policy http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ 6. When to use setuid -vs- RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and 7. Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ 8. Solaris Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ 9. Security questionaire http://opensolaris.org/os/community/arc/bestpractices/security-questions/ 10. Interface Taxonomy http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ 11. Plugable Authentication Modules -- PAM http://opensolaris.org/os/community/arc/policies/PAM/ 12. Reusable Passwords In Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ 13. Storing Reusable Passwords on a Filesystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ 14. Release Taxonomy http://opensolaris.org/os/community/arc/policies/release-taxonomy/ 15. Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Appendix B - Suggested case materials 1. man pages 2. SMF manifests 3. links to contracts Appendix C - Definitions Submitter an agent responsible for creation of an ARC project along with the materials describing that project. Owner the ARC agent responsible for shepherding the case through review and ensuring a formal opinion is written where required. Maintainer an agent responsible for releasing new versions of a program, typically the "main" contributor or person incharge of making Architectural decisions for the project Contributor an agent who make contributions to a project, typically has a voice in making Architectural decisions for the project Monitoring an agent who is only following the changes made in the community and has no Architectural input into the project Volatile* interfaces that are very fluid and typically follow the originating community. Typically these interfaces can not be imported by other projects. Uncommitted* interfaces that are still evolving but will most likely be present from release to release. Committed* interfaces that are stable and with Sun guaranteeing some level of compatibility from release to release. Project Private* interfaces that are exposed only to or intended to be used only by the project being reviewed. These interfaces can not be imported by other projects. Not-An-Interface* components that are not interfaces. Contracted* (interface modifier) - ARC review of Contract required interfaces that do not allow another project to import can be *Note: see http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details --Boundary_(ID_Z8ulSN7+m8SJHbBPvP9b7g) Content-type: text/plain; name=Openwsman-ARC-onepager.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=Openwsman-ARC-onepager.txt 1. Introduction 1.1. Project/Component Working Name: Openwsman 1.2. Name of Document Author/Supplier: Author: Srirama Sharma 1.3 Date of This Document: 5 Januaru 2009 2.0 Project Summary 2.1 Project Description This project introduces the package of Openwsman 2.1.0 into the SFW consolidation. 4. Technical Description Openwsman is a project intended to provide an open-source implementation of the Web Services Management specification (WS-Management) and to expose system management information on the underlying operating system using the WS-Management protocol. WS-Management is based on a suite of web services specifications and usage requirements that exposes a set of operations focused on and covers all system management aspects. Command name Notes ======================================== openwsmand Openwsman daemon 5. Interfaces 5.1 Exported Interfaces Interface Name Classification Comments ------------------------------------------------------- --------------- --------------------------- SUNWopenwsmanu Uncommitted Openwsman user package SUNWopenwsmanr Uncommitted Openwsman root package /usr/sbin/openwsmand Uncommitted Daemon /usr/lib/libwsman.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman.so->libwsman.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman.so.1->libwsman.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_curl_client_transport.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_curl_client_transport.so->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_curl_client_transport.so.1->libwsman_curl_client_transport.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_client.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_client.so->libwsman_client.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_client.so.1->libwsman_client.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_server.so.1.0.0 Uncommitted Shared library /usr/lib/libwsman_server.so->libwsman_server.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_server.so.1->libwsman_server.so.1.0.0 Uncommitted Symbolic link /usr/lib/libwsman_clientpp.so.0.0.0 Uncommitted Shared library /usr/lib/libwsman_clientpp.so->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link /usr/lib/libwsman_clientpp.so.0->libwsman_clientpp.so.0.0.0 Uncommitted Symbolic link /usr/lib/openwsman/ Uncommitted Dir where openwsman libraries are installed /usr/lib/openwsman/plugins Uncommitted Dir where plugins are installed /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/plugins/libwsman_identify_plugin.so->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_identify_plugin.so.1->libwsman_identify_plugin.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_test.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/plugins/libwsman_test.so->libwsman_test.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/plugins/libwsman_test.so.1->libwsman_test.so.1.0.0 Uncommitted Symbolic link /usr/lib/openwsman/authenticators Uncommitted Dir where authenticator libraries are installed /usr/lib/openwsman/authenticators/libwsman_file_auth.so.1.0.0 Uncommitted Shared library /usr/lib/openwsman/authenticators/libwsman_pam_auth.so->libwsman_file_auth.so.1.0.0 Uncommitted Sy mbolic link /usr/lib/openwsman/authenticators/libwsman_pam_auth.so.1->libwsman_file_auth.so.1.0.0 Uncommitted Symbolic link /usr/lib/pkgconfig/openwsman-server.pc Uncommitted Pkgconfig file /usr/lib/pkgconfig/openwsman++.pc Uncommitted Pkgconfig file /usr/lib/pkgconfig/openwsman.pc Uncommitted Pkgconfig file /usr/include/openwsman Uncommitted Dir where openwsman headers are installed. /usr/include/openwsman/wsman-types.h Uncommitted Header file /usr/include/openwsman/wsman-names.h Uncommitted Header file /usr/include/openwsman/wsman-debug.h Uncommitted Header file /usr/include/openwsman/wsman-client.h Uncommitted Header file /usr/include/openwsman/wsman-client-api.h Uncommitted Header file /usr/include/openwsman/wsman-xml-api.h Uncommitted Header file /usr/include/openwsman/wsman-client-transport.h Uncommitted Header file /usr/include/openwsman/wsman-xml-serializer.h Uncommitted Header file /usr/include/openwsman/wsman-xml-serialize.h Uncommitted Header file /usr/include/openwsman/wsman-server-api.h Uncommitted Header file /usr/include/openwsman/wsman-faults.h Uncommitted Header file /usr/include/openwsman/wsman-soap-message.h Uncommitted Header file /usr/include/openwsman/wsman-api.h Uncommitted Header file /usr/include/openwsman/wsman-declarations.h Uncommitted Header file /usr/include/openwsman/wsman-soap.h Uncommitted Header file /usr/include/openwsman/wsman-epr.h Uncommitted Header file /usr/include/openwsman/wsman-filter.h Uncommitted Header file /usr/include/openwsman/wsman-soap-envelope.h Uncommitted Header file /usr/include/openwsman/wsman-subscription-repository.h Uncommitted Header file /usr/include/openwsman/wsman-event-pool.h Uncommitted Header file /usr/include/openwsman/wsman-cimindication-processor.h Uncommitted Header file /usr/include/openwsman/u/buf.h Uncommitted Header file /usr/include/openwsman/u/carpal.h Uncommitted Header file /usr/include/openwsman/u/libu.h Uncommitted Header file /usr/include/openwsman/u/log.h Uncommitted Header file /usr/include/openwsman/u/logprv.h Uncommitted Header file /usr/include/openwsman/u/memory.h Uncommitted Header file /usr/include/openwsman/u/misc.h Uncommitted Header file /usr/include/openwsman/u/os.h Uncommitted Header file /usr/include/openwsman/u/uri.h Uncommitted Header file /usr/include/openwsman/u/uuid.h Uncommitted Header file /usr/include/openwsman/u/lock.h Uncommitted Header file /usr/include/openwsman/u/strings.h Uncommitted Header file /usr/include/openwsman/u/md5.h Uncommitted Header file /usr/include/openwsman/u/list.h Uncommitted Header file /usr/include/openwsman/u/hash.h Uncommitted Header file /usr/include/openwsman/u/base64.h Uncommitted Header file /usr/include/openwsman/u/iniparser.h Uncommitted Header file /usr/include/openwsman/u/debug.h Uncommitted Header file /usr/include/openwsman/u/uerr.h Uncommitted Header file /usr/include/openwsman/u/uoption.h Uncommitted Header file /usr/include/openwsman/u/gettimeofday.h Uncommitted Header file /usr/include/openwsman/u/syslog.h Uncommitted Header file /usr/include/openwsman/u/pthreadx.h Uncommitted Header file /usr/include/openwsman/cim/cim-interface.h Uncommitted Header file /usr/include/openwsman/cpp/OpenWsmanClient.h Uncommitted Header file /usr/include/openwsman/cpp/Exception.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanClient.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanEPR.h Uncommitted Header file /usr/include/openwsman/cpp/WsmanFilter.h Uncommitted Header file /usr/share/man/man8/openwsmand.8 Uncommitted Manpage /etc/openwsman Uncommitted Dir where openwsman config files are installed /etc/openwsman/owsmangencert.sh Uncommitted Script /etc/openwsman/openwsman.conf Uncommitted Config file /etc/openwsman/ssleay.cnf Uncommitted Config file /var/svc/manifest/network/openwsmasnd.xml Uncommitted SVC Manifest file /lib/svc/method/svc-openwsmand Uncommitted SVC Method file Ports 8889 and 8888 Uncommitted Recommended ports for WS-Management 5.2. Imported Interfaces Interface Name Classification Comments --------------------------- ---------------- --------------------------------- /usr/lib/libcurl.so.3 Uncommitted library provided by SUNWcurl pkg /usr/lib/libgss.so.1 Uncommitted library provided by SUNWgss pkg /usr/lib/libidn.so.11 Uncommitted library provided by SUNWgnu-idn pkg /lib/libz.so.1 Uncommitted library provided by SUNWzlibr pkg /lib/libcrypto.so.0.9.8 Uncommitted library provided by SUNWopensslr pkg /lib/libssl.so.0.9.8 Uncommitted library provided by SUNWopensslr pkg /lib/libxml2.so.2 Uncommitted library provided by SUNWlxmlr pkg Ports 5988/5989 Uncommitted Port through which the daemon connects to cimserver through CIM-XML. /lib/libuuid.so.1 Committed library provided by SUNWcslr pkg /lib/libpam.so.1 Committed library provided by SUNWcsl pkg /usr/bin/htpasswd Uncommitted Binary used to generate basic password file /usr/bin/htdigest Uncommitted Binary used to generate digest password file 6. Resources and Schedule 6.4. Product Approval Committee requested information: 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open --Boundary_(ID_Z8ulSN7+m8SJHbBPvP9b7g)-- From Steve.McKinty@sun.com Thu Jan 22 07:09:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0MF9hs8005154 for ; Thu, 22 Jan 2009 07:09:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0MF9fsE028285 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 15:09:42 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDV00A03OS58K00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 07:09:41 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDV001OOOS4Q180@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 07:09:40 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0MF9d3R002057 for ; Thu, 22 Jan 2009 15:09:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDV00E01MHJSG00@fe-emea-09.sun.com> (original mail from Steve.McKinty@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 15:09:39 +0000 (GMT) Received: from [129.157.192.78] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDV00C91ORJPC50@fe-emea-09.sun.com>; Thu, 22 Jan 2009 15:09:20 +0000 (GMT) Date: Thu, 22 Jan 2009 16:09:19 +0100 From: Steve McKinty Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <49788553.3040909@sun.com> Sender: Steve.McKinty@sun.com To: Srirama Sharma Cc: John.Fischer@sun.com, Mark Carlson , LSARC-ext@sun.com Message-id: <49788C1F.6060407@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> <1232467450.2056.2.camel@sr1-umpk-12> <49788553.3040909@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070615) Status: RO Content-Length: 515 Srirama Sharma wrote: > Hi John, > > Please see comments inline. > > John Fischer said the following on Tuesday 20 January 2009 09:34 PM: >> Srirama, >> >> I am assuming, though the proposal does not state, >> that the port numbers are configurable. >> > > Yes, the recommended ports are 8889 and 8888. However these can be > configured in "/etc/openwsman/openwsman.conf". IANA shows those ports as being registered to something else, have you made a request to register ports for 'official' use? Steve From Mark.Carlson@sun.com Thu Jan 22 08:55:06 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0MGt4Ev024960 for ; Thu, 22 Jan 2009 08:55:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0MGsrCD026506 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 00:55:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDV00F1RTNKWB00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 22 Jan 2009 08:54:57 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDV00EHMTNF3H30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 22 Jan 2009 08:54:52 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0MGspVf026760 for ; Thu, 22 Jan 2009 16:54:51 +0000 (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 <0KDV00301SLM5E00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 22 Jan 2009 09:54:51 -0700 (MST) Received: from Macintosh-335.local ([64.244.64.2]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDV00NC7TMS2N80@mail-amer.sun.com>; Thu, 22 Jan 2009 09:54:29 -0700 (MST) Date: Thu, 22 Jan 2009 09:54:26 -0700 From: "Mark A. Carlson" Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <49788C1F.6060407@sun.com> Sender: Mark.Carlson@sun.com To: Steve McKinty Cc: Srirama Sharma , John.Fischer@sun.com, Mark Carlson , LSARC-ext@sun.com Message-id: <4978A4C2.7050002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> <1232467450.2056.2.camel@sr1-umpk-12> <49788553.3040909@sun.com> <49788C1F.6060407@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 860 These are the official ones: wsman 5985/tcp WBEM WS-Management HTTP wsman 5985/udp WBEM WS-Management HTTP wsmans 5986/tcp WBEM WS-Management HTTP over TLS/SSL wsmans 5986/udp WBEM WS-Management HTTP over TLS/SSL The project should default to these. -- mark Steve McKinty wrote: > > > Srirama Sharma wrote: >> Hi John, >> >> Please see comments inline. >> >> John Fischer said the following on Tuesday 20 January 2009 09:34 PM: >>> Srirama, >>> >>> I am assuming, though the proposal does not state, >>> that the port numbers are configurable. >>> >> >> Yes, the recommended ports are 8889 and 8888. However these can be >> configured in "/etc/openwsman/openwsman.conf". > > IANA shows those ports as being registered to something else, have you > made > a request to register ports for 'official' use? > > Steve > From Srirama.Sharma@sun.com Fri Jan 23 03:45:00 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0NBix9U024015 for ; Fri, 23 Jan 2009 03:45:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0NBilUH002249 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 19:44:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDX00J039YUT900@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 03:44:54 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDX00J389YTIED0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 03:44:53 -0800 (PST) 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 n0NBirko021485 for ; Fri, 23 Jan 2009 11:44:53 +0000 (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 <0KDX004019QHVL00@mail-amer.sun.com> (original mail from Srirama.Sharma@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 04:44:53 -0700 (MST) Received: from [10.114.58.72] ([203.91.196.62]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDX00ISM9YQACD0@mail-amer.sun.com>; Fri, 23 Jan 2009 04:44:53 -0700 (MST) Date: Fri, 23 Jan 2009 17:12:48 +0530 From: Srirama Sharma Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <200901210625.n0L6PRvA002179@marduk.eng.sun.com> Sender: Srirama.Sharma@sun.com To: Gary Winiger Cc: LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com, Srirama Sharma Message-id: <4979AD38.6050407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901210625.n0L6PRvA002179@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070604) Status: RO Content-Length: 482 Hi Gary, Gary Winiger said the following on Wednesday 21 January 2009 11:55 AM: > * What is the analysis of the security implications of this project > vis-a-vis currently delivered Sun SNMP? Other than viewing/reporting, what > type of administrative file/database modifications/changes does this project > permit? > This project is merely a protocol adapter and not the instrumentation that would allow modification or even viewing/reporting on its own. Thanks, Srirama From Srirama.Sharma@sun.com Fri Jan 23 05:48:04 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0NDm3Sv013883 for ; Fri, 23 Jan 2009 05:48:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0NDlvDX016115 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 13:48:02 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDX0030HFO1DO00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Fri, 23 Jan 2009 05:48:01 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDX002UBFNZOI20@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Fri, 23 Jan 2009 05:48:00 -0800 (PST) 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 n0NDlx0J013138 for ; Fri, 23 Jan 2009 13:47:59 +0000 (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 <0KDX00L01FGIJX00@mail-amer.sun.com> (original mail from Srirama.Sharma@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Fri, 23 Jan 2009 06:47:59 -0700 (MST) Received: from [10.114.58.72] ([203.91.196.62]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDX008CHFNP23D0@mail-amer.sun.com>; Fri, 23 Jan 2009 06:47:53 -0700 (MST) Date: Fri, 23 Jan 2009 19:15:47 +0530 From: Srirama Sharma Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <4978A4C2.7050002@sun.com> Sender: Srirama.Sharma@sun.com To: "Mark A. Carlson" Cc: Steve McKinty , john.fischer@sun.com, Mark Carlson , LSARC-ext@sun.com, Srirama Sharma Message-id: <4979CA0B.4080800@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> <1232467450.2056.2.camel@sr1-umpk-12> <49788553.3040909@sun.com> <49788C1F.6060407@sun.com> <4978A4C2.7050002@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070604) Status: RO Content-Length: 1101 Hi, I will make changes to the configuration file to make use of these ports (5985 and 5986) by default. Thanks, Srirama Mark A. Carlson said the following on Thursday 22 January 2009 10:24 PM: > These are the official ones: > > wsman 5985/tcp WBEM WS-Management HTTP > wsman 5985/udp WBEM WS-Management HTTP > wsmans 5986/tcp WBEM WS-Management HTTP over TLS/SSL > wsmans 5986/udp WBEM WS-Management HTTP over TLS/SSL > > The project should default to these. > > -- mark > > Steve McKinty wrote: >> >> >> Srirama Sharma wrote: >>> Hi John, >>> >>> Please see comments inline. >>> >>> John Fischer said the following on Tuesday 20 January 2009 09:34 PM: >>>> Srirama, >>>> >>>> I am assuming, though the proposal does not state, >>>> that the port numbers are configurable. >>>> >>> >>> Yes, the recommended ports are 8889 and 8888. However these can be >>> configured in "/etc/openwsman/openwsman.conf". >> >> IANA shows those ports as being registered to something else, have >> you made >> a request to register ports for 'official' use? >> >> Steve >> From Mark.Carlson@sun.com Tue Jan 27 10:00:48 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0RI0mDc015159 for ; Tue, 27 Jan 2009 10:00:48 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0RI0lSc052092 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 27 Jan 2009 11:00:47 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE50021X60YJ400@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 27 Jan 2009 11:00:34 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE5007WU60RICD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 27 Jan 2009 11:00:32 -0700 (MST) 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 n0RI0RRW007557 for ; Tue, 27 Jan 2009 18:00:27 +0000 (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 <0KE500E0148EU000@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 27 Jan 2009 11:00:27 -0700 (MST) Received: from Macintosh-335.local ([129.150.34.235]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE5009WU60O1BF0@mail-amer.sun.com>; Tue, 27 Jan 2009 11:00:25 -0700 (MST) Date: Tue, 27 Jan 2009 11:00:24 -0700 From: "Mark A. Carlson" Subject: LSARC/2009/035 Contract for Openwsman to use Openssl interfaces Sender: Mark.Carlson@sun.com To: Anup Sekhar Cc: LSARC-ext@sun.com, Srirama Sharma Message-id: <497F4BB8.5060300@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4x0C64gvhJ+Cxcz8EPWEew)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 8041 This is a multi-part message in MIME format. --Boundary_(ID_4x0C64gvhJ+Cxcz8EPWEew) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Anup, Please reply-all to this email indicating you accept this contract. Thanks, -- mark --Boundary_(ID_4x0C64gvhJ+Cxcz8EPWEew) Content-type: text/plain; name=openwsman-ssl-contract.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=openwsman-ssl-contract.txt CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2003/500-31 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 WOS Consolidation: ON Department or Group: Solaris Security Technology Group (SSTG) Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl Responsible Manager: Anup Sekhar Contact: contract-2003-500@sun.com 3. The CONSUMER is identified by the following: Product or Bundle: Solaris WOS Consolidation: sfw Department or Group: Open Solaris Bugtraq Category/SubCategory: solaris/wbem/openwsman Responsible Manager: kenneth.davis@sun.com Packages: SUNWopenwsmanu, SUNWopenwsmanr Contact: SPSG_Indiana_Team@sun.com 4. The INTERFACES are: The interfaces covered by this contract are limited to a subset of the C programming APIs that the OpenSSL communittee has choosen to document in man pages. It is the subset that the SUPPLIER beleives to be reasonably stable. That subset covers the following major subsystems: ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND, SMIME, SSL, BIO, X509 In particular it does NOT cover "direct use" of encryption algorithm APIs outside of the EVP_ interfaces, eg do not call DES or AES except via EVP_Encrypt*() This contract does NOT cover the use of the openssl(1) command as an interface to be consumed. This contract does NOT cover any API or implementation artifact that does not have an OpenSSL delivered man page. OpenSSL Package names SUNWopenssl-include Unstable SUNWopenssl-libraries Unstable OpenSSL Library Location /usr/sfw/lib/libcrypto.so Unstable /usr/sfw/lib/libssl.so Unstable OpenSSL Headers Location /usr/sfw/include/openssl/*.h UnStable ASN1_ External BN_ External BIO_ External CRYPTO_ External EVP_ External HMAC External OpenSSL_ External OBJ_ External PEM_ External PKCS7 External PKCS12_ External RAND_ External SMIME_ External SSL_ External X509_ External 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2003/500 Note: this contract is not about a specific version of OpenSSL. It covers version 0.9.7d from PSARC/2003/500 and all subsequent versions. If a change in the OpenSSL interfaces requires an update of the contract then OpenSSL iteam will contact the consumer. 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _Y_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: The SUPPLIER will modify the interfaces as needed by the evolution of OpenSSL releases shipped by on the www.openssl.org site. _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. This contract is only avaliable for CONSUMERS who deliver directly to the Solaris WOS. If a contract for a CONSUMER who is not part of the Solaris WOS is requested it will be dealt with by ARC and the SUPPLIER as a new contract. _Y_ 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 will have simultaneous conversion to the new interfaces. The SUPPLIER will make a best effort to do most of the work, but the CONSUMER must be willing to supply resources to assist with modification/testing of their consuming code if necessary. Only a single version of the INTERFACES will be available at any one time. 8. If CONSUMER requires changes in INTERFACES, they must work with the OpenSSL communittee. The SUPPLIER is willing to assist with this process on a best effort to accommodate such changes. In general INTERFACE changes will not be made unless they come from the OpenSSL communittee. 9. N/A 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will update the OpenSSL code base in the ON consolidation on an as needed basis. The trigger for these events is based on the externally defined schedule of the OpenSSL communittee. The SUPPLIER will inform the CONSUMER(S) of this change via the contract alias before filing the RTI for integration into ON. Note that it may be necessary to update INTERFACES (or more likely the implementations of them) with less than 5 working days notice. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The SUPPLIER will NOT provide any assistance for use of the interfaces they are Externally defined and the SUPPLIER is not necessarily an expert in their use. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The only documentation will be that provided by the OpenSSL communittee, it will be shipped in the SUNWopenssl-man package in the form of Solaris nroff man pages. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Before each intergration the OpenSSL test suites will be run. The standard for "PASS" is that the version in the ON gate should produce the same functionality as binaries built using the OpenSSL makefiles for the same processor architecture. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: The CONSUMER may choose to terminate this contract at any time by sending email to the contract-2003-500@sun.com alias. The SUPPLIER may terminate this contract only after giving suffient notice to the CONSUMER. Sufficient notice in the case of CONSUMERS that are external to the ON consolidation must take into account the Solaris WOS build schedule and its restrictions for change. The SUPPLIER will terminate this contract if the interfaces are ever reclassified to something other than External. 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: Anup Sekhar Date: For CONSUMER: Srirama Sharma Date: 01/27/2009 For ARC: Mark Carlson Date: A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: --Boundary_(ID_4x0C64gvhJ+Cxcz8EPWEew)-- From Mark.Carlson@sun.com Tue Jan 27 10:14:51 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0RIEp1j016824 for ; Tue, 27 Jan 2009 10:14:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0RIERXD003313 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 27 Jan 2009 10:14:51 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE50071J6OPRS00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 27 Jan 2009 10:14:49 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE500KVC6ONBOC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 27 Jan 2009 10:14:48 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0RIEluO007250 for ; Tue, 27 Jan 2009 18:14:47 +0000 (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 <0KE5003014ZU6300@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 27 Jan 2009 11:14:47 -0700 (MST) Received: from Macintosh-335.local ([129.150.34.235]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE500I1S6OBL150@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 27 Jan 2009 11:14:36 -0700 (MST) Date: Tue, 27 Jan 2009 11:14:32 -0700 From: "Mark A. Carlson" Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> Sender: Mark.Carlson@sun.com To: LSARC-ext@sun.com Cc: Srirama.Sharma@sun.com Message-id: <497F4F08.1050803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901200601.n0K61Mhs013939@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 48 This case was approved in LSARC today. -- mark From Anup.Sekhar@sun.com Tue Jan 27 11:17:00 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0RJGx0W019571 for ; Tue, 27 Jan 2009 11:16:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0RJGeXI022842; Wed, 28 Jan 2009 03:16:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE50020R9K71100@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Jan 2009 11:16:55 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE500ICR9K6DC80@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Jan 2009 11:16:54 -0800 (PST) Received: from dhcp-umpk17-107-238.SFBay.Sun.COM (dhcp-umpk17-107-238.SFBay.Sun.COM [129.146.107.238]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0RJG5NV148095; Tue, 27 Jan 2009 11:16:53 -0800 (PST) Date: Tue, 27 Jan 2009 11:16:54 -0800 From: Anup Sekhar Subject: Re: LSARC/2009/035 Contract for Openwsman to use Openssl interfaces In-reply-to: <497F4BB8.5060300@sun.com> To: "Mark A. Carlson" Cc: LSARC-ext@sun.com, Srirama Sharma , contract-2003-500@sun.com Message-id: <9F47F6F5-1D5E-4BE3-B4E4-A20965937D97@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <497F4BB8.5060300@sun.com> Status: RO Content-Length: 8100 I approve this contract as the SUPPLIER. Anup On Jan 27, 2009, at 10:00 AM, Mark A. Carlson wrote: > Anup, > > Please reply-all to this email indicating you accept this contract. > > Thanks, > > -- mark > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2003/500-31 > > 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 WOS > Consolidation: ON > Department or Group: Solaris Security Technology Group (SSTG) > Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl > Responsible Manager: Anup Sekhar > Contact: contract-2003-500@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris WOS > Consolidation: sfw > Department or Group: Open Solaris > Bugtraq Category/SubCategory: solaris/wbem/openwsman > Responsible Manager: kenneth.davis@sun.com > Packages: SUNWopenwsmanu, SUNWopenwsmanr > Contact: SPSG_Indiana_Team@sun.com > > 4. The INTERFACES are: > > The interfaces covered by this contract are limited to a subset > of the C programming APIs that the OpenSSL communittee has > choosen to document in man pages. It is the subset that the > SUPPLIER beleives to be reasonably stable. > > That subset covers the following major subsystems: > > ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND, > SMIME, SSL, BIO, X509 > > In particular it does NOT cover "direct use" of encryption algorithm > APIs outside of the EVP_ interfaces, eg do not call DES or AES > except via EVP_Encrypt*() > > This contract does NOT cover the use of the openssl(1) command > as an interface to be consumed. > > This contract does NOT cover any API or implementation artifact > that does not have an OpenSSL delivered man page. > > OpenSSL Package names > > SUNWopenssl-include Unstable > SUNWopenssl-libraries Unstable > > OpenSSL Library Location > > /usr/sfw/lib/libcrypto.so Unstable > /usr/sfw/lib/libssl.so Unstable > > OpenSSL Headers Location > > /usr/sfw/include/openssl/*.h UnStable > > ASN1_ External > BN_ External > BIO_ External > CRYPTO_ External > EVP_ External > HMAC External > OpenSSL_ External > OBJ_ External > PEM_ External > PKCS7 External > PKCS12_ External > RAND_ External > SMIME_ External > SSL_ External > X509_ External > > > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing these INTERFACES is: PSARC/2003/500 > > Note: this contract is not about a specific version of OpenSSL. > It covers > version 0.9.7d from PSARC/2003/500 and all subsequent versions. > If a > change in the OpenSSL interfaces requires an update of the > contract then > OpenSSL iteam will contact the consumer. > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _Y_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > The SUPPLIER will modify the interfaces as needed by the > evolution > of OpenSSL releases shipped by on the www.openssl.org site. > > _N_ 7b. Although the stability level doesn't normally allow it, > CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, > namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, > CONSUMER will > import INTERFACES from a separate consolidation. > > This contract is only avaliable for CONSUMERS who deliver > directly > to the Solaris WOS. > > If a contract for a CONSUMER who is not part of the Solaris > WOS is > requested it will be dealt with by ARC and the SUPPLIER as a > new > contract. > > _Y_ 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 will have simultaneous conversion to the > new interfaces. > The SUPPLIER will make a best effort to do most of the work, but > the CONSUMER must be willing to supply resources to assist with > modification/testing of their consuming code if necessary. > > Only a single version of the INTERFACES will be available at any > one time. > > 8. If CONSUMER requires changes in INTERFACES, they must work with the > OpenSSL communittee. The SUPPLIER is willing to assist with this > process on a best effort to accommodate such changes. > In general INTERFACE changes will not be made unless they come from > the OpenSSL communittee. > > 9. N/A > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > The SUPPLIER will update the OpenSSL code base in the ON > consolidation > on an as needed basis. The trigger for these events is based on > the > externally defined schedule of the OpenSSL communittee. > > The SUPPLIER will inform the CONSUMER(S) of this change via the > contract alias before filing the RTI for integration into ON. > > Note that it may be necessary to update INTERFACES (or more likely > the implementations of them) with less than 5 working days notice. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > The SUPPLIER will NOT provide any assistance for use of the > interfaces > they are Externally defined and the SUPPLIER is not necessarily an > expert in their use. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The only documentation will be that provided by the OpenSSL > communittee, it will be shipped in the SUNWopenssl-man package > in the form of Solaris nroff man pages. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > Before each intergration the OpenSSL test suites will be run. The > standard for "PASS" is that the version in the ON gate should > produce > the same functionality as binaries built using the OpenSSL > makefiles > for the same processor architecture. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated > as > follows: > > The CONSUMER may choose to terminate this contract at any time by > sending email to the contract-2003-500@sun.com alias. > > The SUPPLIER may terminate this contract only after giving suffient > notice to the CONSUMER. Sufficient notice in the case of > CONSUMERS > that are external to the ON consolidation must take into account > the > Solaris WOS build schedule and its restrictions for change. > > The SUPPLIER will terminate this contract if the interfaces > are ever reclassified to something other than External. > > 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: Anup Sekhar Date: > For CONSUMER: Srirama Sharma Date: 01/27/2009 > For ARC: Mark Carlson Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > From gww@sac.sfbay.sun.com Tue Jan 27 12:01:54 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0RK1sVk007322 for ; Tue, 27 Jan 2009 12:01:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0RK1qIp002903 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Tue, 27 Jan 2009 13:01:54 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE50050FBN51M00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 27 Jan 2009 12:01:53 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE500IXXBN4DHB0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 27 Jan 2009 12:01:53 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0RK1ptB041260; Tue, 27 Jan 2009 12:01:51 -0800 (PST) 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 n0RK1p18006838; Tue, 27 Jan 2009 12:01:51 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n0RK1o7U006827; Tue, 27 Jan 2009 12:01:50 -0800 (PST) Date: Tue, 27 Jan 2009 12:01:50 -0800 (PST) From: Gary Winiger Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] To: Srirama.Sharma@sun.com, gww@eng.sun.com Cc: LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com Message-id: <200901272001.n0RK1o7U006827@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7420 > > I see what looks like a possible mention of a service manifest, but no mention > > of an FMRI, method context, administrative authorizations, Rights Profiles, > > properties such as local_only, .... I'd expect the man page to discuss at > > least the FMRI, Rights Profiles and properties. > > > > This service is manged under the FMRI "svc:/network/openwsmand" > > No specific Rights Profiles are getting added to > "/etc/security/prof_attr". Instead, below "method_context" is defined in > the manifest file for all the methods i.e start, stop and refresh. What are the required value and action authroizations? And in what Rights Profile are they found? > > user='root' > group='root' > privileges='basic' > /> > Why is root necessary? Should the service be exploited, this leads the system vulnerable. > Could you please confirm if below text is sufficient under the NOTES > section of the man page: > > "openwsmand service is by default disabled and it is managed by the > service management facility, smf(5), under the service identifier: > > svc:/network/openwsmand > > Administrative actions on this service, such as enabling, > disabling, or refreshing, can be performed using svcadm(1M). > The service's status can be queried using the svcs(1) command" This is where you document the Rights Profile that permits the use of svcadm enable/disable and any application properties that are to be administered. > > * The man page states: "openwsmand service can be started only by > > a privileged user." In the light of Solaris Privileges, SMF and RBAC > > what does this mean? > > > > Administrative actions on this service, such as enabling, disabling, > or refreshing, can be performed using svcadm(1M). See above. > All these methods (start, stop and refresh) have below method context. > So no new RBAC profile has been added. > > > user='root' > group='root' > privileges='basic' > /> > Again see above. > > * The Check List says this project uses PAM and the man page shows: > > /etc/pam.d/openwsman: > > > > #%PAM-1.0 > > auth required pam_unix2.so nullok > > auth required pam_nologin.so > > account required pam_unix2.so > > password required pam_pwcheck.so nullok > > password required pam_unix2.so nullok use_first_pass use_authtok > > session required pam_unix2.so none > > > > None of these PAM modules seem to be delivered by this project and > > are otherwise not part of OpenSolaris. > > Yes. The openwsman daemon can be configured to use PAM for > authentication. By default, it only uses file based authentication > where in password files generated using htpasswd/htdigest are used. > > The man page only shows a template pam.conf (the one which was available > with the community source tarball). The pam.conf is currently not > getting shipped as part of this package. The administrator has to create > appropriate pam.conf in which the pam modules already delivered with > OpenSolaris or any site specifc pam module could be made use of. > > Please advice if man page needs to be modified to show an example which > makes use of generic pam modules which are part of OpenSolaris. IMO if the project ships something on OpenSolaris, and it is has some configuration, it is incumbent on the project team to correctly document how to configure the project on OpenSolaris. > > Furthermore, the imported interfaces do not show libpam. > > > Done. Have added libpam entry into the imported interface table with > stability "committed". Is the stability correct ? Yes. > > * The imported interfaces appear to show the use of OpenSSL. IIRC, > > it's use is contracted. I don't find a mention of the contract. > > > > Will check with Mark on the status and revert back. IMO, Before the case closes, this needs to be answered. IMO, Before the case integrates, any necessary contracts need to be out for signature. > > * This project appears to do authentication, yet I don't see mention > > of how that authentication is audited or a discussion why it shouldn't be. > > The reference for the Check List auditing section seems to say to me if the > > project does authentication, it audits that authentication. > > > > > openwsman daemon has a command line option to enable syslog and set the > verbosity of the syslog output. syslog != auditing. See the SAC policy. > Also, here the users who are getting authenticated by openwsmand are not > Solaris users. These are the users created using htpasswd/htdigest with > OPENWSMAN realm by default. But when it is configured to use PAM, it > could make use of /etc/paswd and /etc/shadow to check the credentials of > the user. So is Solaris auditing required in this case ? If you're authenticating Solaris users, probably unless you can argue that the only access they have is to view public information. It seems to me that if there's any thing other than view access to public information, auditing that that access was granted even if not to a Solaris user would be interesting to a system auditor. So, I guess it all boils down to what type of access the openwsman service enables. > > * The Check List says: "The openwsman daemon is sufficiently privileged > > to authenticate the wsman client. There will be no request for a password > > change coming in over the wire via WS-Man." With Solaris Privileges, what > > does "sufficiently privileged ..." mean? > > As specified in the method_context in the manifest file, the daemon will > be started with uid and gid as root and with basic privileges. Why root? Why is basic required? If root why not no privs. > > If there is no password change over the wire, how exactly are passwords managed? > > The administrator will have to use htpasswd/htdigest to recreate the new > password and install the same into the current simple/digest password > files (default located in /etc/openwsman dir) . And how is write allowed to these commands to the /etc/openwsman directory? Perhaps they should be in the same Rights Profile as the action and value authorizations. > > * The Check List says: "If the openwsman daemon is configured to use > > PAM, then the service configuration file provided by the administrator in > > /etc/pam.d will be used." Is PAM configured? See above about the use > > of PAM. > When Openwsman daemon is configured to use PAM for authentication, > openwsman pam plugin library in turn links to libpam and makes use of > function calls like pam_start(), pam_authenticate() and pam_stop () to > authenticate the user. Well, it should really be pam_start, pam_authenticate, pam_acct_mgmt, pam_end. The real point is above to have a proper pam.conf stack. Note also that the PAM service name is an exported interface and needs to be documented in the man page. Presumably it is openwsman. Gary.. From Srirama.Sharma@sun.com Wed Feb 25 07:28:52 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PFSqpW014581 for ; Wed, 25 Feb 2009 07:28:52 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1PFSoSI008104 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 25 Feb 2009 07:28:52 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM0041DOC22L00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 25 Feb 2009 08:28:50 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00CQEOC1GC90@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 25 Feb 2009 08:28:49 -0700 (MST) 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 n1PFSnGA007329 for ; Wed, 25 Feb 2009 15:28:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFM00J00NJ1JP00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 25 Feb 2009 08:28:49 -0700 (MST) Received: from [10.114.58.72] ([unknown] [203.91.196.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFM00J51OBIKBE0@mail-amer.sun.com>; Wed, 25 Feb 2009 08:28:36 -0700 (MST) Date: Wed, 25 Feb 2009 20:55:34 +0530 From: Srirama Sharma Subject: Re: Openwsman [LSARC/2009/035 FastTrack timeout 01/26/2009] In-reply-to: <200901272001.n0RK1o7U006827@sac.sfbay.sun.com> Sender: Srirama.Sharma@sun.com To: Gary Winiger Cc: gww@eng.sun.com, LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com, Srirama Sharma Message-id: <49A562EE.8020204@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_STyC01Vpb1VxarZdnrYmPg)" X-PMX-Version: 5.4.1.325704 References: <200901272001.n0RK1o7U006827@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070604) Status: RO Content-Length: 23650 This is a multi-part message in MIME format. --Boundary_(ID_STyC01Vpb1VxarZdnrYmPg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary, Sorry for the late reply. Had already incorporated all the changes suggested by you, missed replying here. Please see reply in line. Gary Winiger said the following on Wednesday 28 January 2009 01:31 AM: >>> I see what looks like a possible mention of a service manifest, but no mention >>> of an FMRI, method context, administrative authorizations, Rights Profiles, >>> properties such as local_only, .... I'd expect the man page to discuss at >>> least the FMRI, Rights Profiles and properties. >>> >>> >> This service is manged under the FMRI "svc:/network/openwsmand" >> >> No specific Rights Profiles are getting added to >> "/etc/security/prof_attr". Instead, below "method_context" is defined in >> the manifest file for all the methods i.e start, stop and refresh. >> > > What are the required value and action authroizations? And > in what Rights Profile are they found? > > Have added "solaris.smf.value.openwsmand" & "solaris.smf.manage.openwsmand" authorizations to /etc/security/auth_attr file as shown below: solaris.smf.value.openwsmand:::Change openwsmand value properties:: solaris.smf.manage.openwsmand:::Manage openwsmand value properties:: Also have added new Rights profile "Openwsman Server Administration" into /etc/security/prof_attr file and have assigned these authorizations to the new Rights Profile as below: Openwsman Server Administration::::auths=solaris.smf.manage.openwsmand,solaris.smf.value.openwsmand >> >> > user='root' >> group='root' >> privileges='basic' >> /> >> >> > > Why is root necessary? Should the service be exploited, this > leads the system vulnerable. > As per your suggestion have now added the authorizations and the Rights profile. Hence have removed the above method context from the SMF manifest file. > >> Could you please confirm if below text is sufficient under the NOTES >> section of the man page: >> >> "openwsmand service is by default disabled and it is managed by the >> service management facility, smf(5), under the service identifier: >> >> svc:/network/openwsmand >> >> Administrative actions on this service, such as enabling, >> disabling, or refreshing, can be performed using svcadm(1M). >> The service's status can be queried using the svcs(1) command" >> > > This is where you document the Rights Profile that permits > the use of svcadm enable/disable and any application properties > that are to be administered. > > Done. Have modified the man page to have below SMF section which documents about the SVC FMRI, SMF methods and the information on the Rights profile. Service Management Framework (SMF) openwsmand openwsmand service is by default disabled and it is managed by the service management facility, smf(5), under the service identifier: svc:/network/openwsmand Administrative actions on this service, such as enabling, disabling, or refreshing, can be performed using svcadm(1M). 1) To start the openwsmand service example% svcadm enable network/openwsmand 2) To disable or stop the openwsmand service example% svcadm disable network/openwsmand By default only root user will be able to perform the admin- istrative actions. However otherwise non-privileged user can be authorized to perform administrative actions through RBAC(5). For example, to let a user 'wsman' change openwsmand value properties and manage openwsmand service states, assign "Openwsman Server Administration" Rights Profile to the user. This can be done by adding the following line to /etc/user_attr: wsman::::profiles=Openwsman Server Administration Specific authorizations either to manage the service or change the value properties can also be assigned to the user by assigning either solaris.smf.manage.openwsmand or solaris.smf.value.openwsmand authorizations respectively to the user in /etc/user_attr. For example, to authorize a user 'wsman1' to only manage the service state and not change the value properties, add the following line to /etc/user_attr: wsman1::::auths=solaris.smf.manage.openwsmand The service's status can be queried using the svcs(1) com- mand >>> * The man page states: "openwsmand service can be started only by >>> a privileged user." In the light of Solaris Privileges, SMF and RBAC >>> what does this mean? >>> >>> >> Administrative actions on this service, such as enabling, disabling, >> or refreshing, can be performed using svcadm(1M). >> > > See above. > Done. Please see above. > >> All these methods (start, stop and refresh) have below method context. >> So no new RBAC profile has been added. >> >> >> > user='root' >> group='root' >> privileges='basic' >> /> >> >> > > Again see above. > Done. Please see above. > >>> * The Check List says this project uses PAM and the man page shows: >>> /etc/pam.d/openwsman: >>> >>> #%PAM-1.0 >>> auth required pam_unix2.so nullok >>> auth required pam_nologin.so >>> account required pam_unix2.so >>> password required pam_pwcheck.so nullok >>> password required pam_unix2.so nullok use_first_pass use_authtok >>> session required pam_unix2.so none >>> >>> None of these PAM modules seem to be delivered by this project and >>> are otherwise not part of OpenSolaris. >>> >> Yes. The openwsman daemon can be configured to use PAM for >> authentication. By default, it only uses file based authentication >> where in password files generated using htpasswd/htdigest are used. >> >> The man page only shows a template pam.conf (the one which was available >> with the community source tarball). The pam.conf is currently not >> getting shipped as part of this package. The administrator has to create >> appropriate pam.conf in which the pam modules already delivered with >> OpenSolaris or any site specifc pam module could be made use of. >> >> Please advice if man page needs to be modified to show an example which >> makes use of generic pam modules which are part of OpenSolaris. >> > > IMO if the project ships something on OpenSolaris, and it is > has some configuration, it is incumbent on the project team > to correctly document how to configure the project on > OpenSolaris. > Done. The man page now has an example for OpenSolaris mentioning the PAM modules available in OpenSolaris along with the example which was available for Linux. >>> * The imported interfaces appear to show the use of OpenSSL. IIRC, >>> it's use is contracted. I don't find a mention of the contract. >>> >>> >> Will check with Mark on the status and revert back. >> > > IMO, Before the case closes, this needs to be answered. > IMO, Before the case integrates, any necessary contracts need > to be out for signature. > Done. Have already got the contract PSARC/2003/500-31 signed. I will check with Mark if he has updated the case materials to have the signed contract >>> * The Check List says: "The openwsman daemon is sufficiently privileged >>> to authenticate the wsman client. There will be no request for a password >>> change coming in over the wire via WS-Man." With Solaris Privileges, what >>> does "sufficiently privileged ..." mean? >>> >> As specified in the method_context in the manifest file, the daemon will >> be started with uid and gid as root and with basic privileges. >> > > Why root? Why is basic required? If root why not no privs. > As mentioned above, the method_context has been removed and have added the Rights Profile and the required Authorizations for the same. > >>> If there is no password change over the wire, how exactly are passwords managed? >>> >> The administrator will have to use htpasswd/htdigest to recreate the new >> password and install the same into the current simple/digest password >> files (default located in /etc/openwsman dir) . >> > > And how is write allowed to these commands to the /etc/openwsman > directory? Perhaps they should be in the same Rights Profile > as the action and value authorizations. > > Done. > >> When Openwsman daemon is configured to use PAM for authentication, >> openwsman pam plugin library in turn links to libpam and makes use of >> function calls like pam_start(), pam_authenticate() and pam_stop () to >> authenticate the user. >> > > Well, it should really be pam_start, pam_authenticate, > pam_acct_mgmt, pam_end. > > The real point is above to have a proper pam.conf stack. > Note also that the PAM service name is an exported interface > and needs to be documented in the man page. Presumably > it is openwsman. > Yes. The authentication is happening in the same order as you have mentioned. Have added proper pam.conf entries for OpenSolaris in the man page. Thanks, Srirama --Boundary_(ID_STyC01Vpb1VxarZdnrYmPg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary,

Sorry for the late reply. Had already incorporated all the changes suggested by you, missed replying here.

Please see reply in line.

Gary Winiger said the following on Wednesday 28 January 2009 01:31 AM: 
I see what looks like a possible  mention of a service manifest, but no mention
of an FMRI, method context, administrative authorizations, Rights Profiles,
properties such as local_only, ....  I'd expect the man page to discuss at
least the FMRI, Rights Profiles and properties.
  
      
This service is manged under the FMRI "svc:/network/openwsmand"

No specific Rights Profiles are getting added to 
"/etc/security/prof_attr". Instead, below "method_context" is defined in 
the manifest file for all the methods i.e start, stop and refresh.
    

	What are the required value and action authroizations?  And
	in what Rights Profile are they found?

Have added "solaris.smf.value.openwsmand" & "solaris.smf.manage.openwsmand" authorizations to /etc/security/auth_attr file as shown below:

solaris.smf.value.openwsmand:::Change openwsmand value properties::
solaris.smf.manage.openwsmand:::Manage openwsmand value properties::


Also have added new Rights profile "Openwsman Server Administration" into /etc/security/prof_attr file and have assigned these authorizations to the new Rights Profile as below:
Openwsman Server Administration::::auths=solaris.smf.manage.openwsmand,solaris.smf.value.openwsmand


 
                <method_context>
                        <method_credential
                        user='root'
                        group='root'
                        privileges='basic'
                        />
                </method_context>
    

	Why is root necessary?  Should the service be exploited, this
	leads the system vulnerable.

As per your suggestion have now added the authorizations and the Rights profile. Hence have removed the above method context from the SMF manifest file.


  
Could you please confirm if below text is sufficient under the NOTES 
section of the man page:

    "openwsmand service is by default disabled and it is managed by the
    service management facility, smf(5), under the service identifier:

    svc:/network/openwsmand

    Administrative actions on this service,  such  as  enabling,
    disabling,  or  refreshing,  can be performed using svcadm(1M).
    The service's status can be  queried  using  the svcs(1) command"
    

	This is where you document the Rights Profile that permits
	the use of svcadm enable/disable and any application properties
	that are to be administered.

Done. Have modified the man page to have below SMF section which documents about the SVC FMRI, SMF methods and the information on the Rights profile.


Service Management Framework (SMF)
     openwsmand openwsmand service is by default disabled and  it
     is managed by the service management facility, smf(5), under
     the service identifier:

        svc:/network/openwsmand

     Administrative actions on this service,  such  as  enabling,
     disabling,    or    refreshing,    can  be  performed  using
     svcadm(1M).

       1) To start the openwsmand service
               example% svcadm enable network/openwsmand

       2) To disable or stop the openwsmand service
               example% svcadm disable network/openwsmand

     By default only root user will be able to perform the admin-
     istrative actions. However otherwise non-privileged user can
     be authorized  to  perform  administrative  actions  through
     RBAC(5).

     For example, to let a user 'wsman' change  openwsmand  value
     properties  and  manage  openwsmand  service  states, assign
     "Openwsman Server  Administration"  Rights  Profile  to  the
     user.  This  can  be  done  by  adding the following line to
     /etc/user_attr:

        wsman::::profiles=Openwsman Server Administration

     Specific authorizations either  to  manage  the  service  or
     change the value properties can also be assigned to the user
     by   assigning   either   solaris.smf.manage.openwsmand   or
     solaris.smf.value.openwsmand  authorizations respectively to
     the user in /etc/user_attr.

     For example, to authorize a user 'wsman1' to only manage the
     service  state  and not change the value properties, add the
     following line to /etc/user_attr:

        wsman1::::auths=solaris.smf.manage.openwsmand

     The service's status can be queried  using  the svcs(1) com-
     mand

	* The man page states: "openwsmand service can be started only by
a privileged user."  In the light of Solaris Privileges, SMF and RBAC
what does this mean?
  
      
Administrative actions on this service,  such  as  enabling, disabling,  
or  refreshing,  can be performed using svcadm(1M).
    

	See above.

Done. Please see above.

  
All these methods (start, stop and refresh) have below method context. 
So no new RBAC profile has been added.

                <method_context>
                        <method_credential
                        user='root'
                        group='root'
                        privileges='basic'
                        />
                </method_context>
    

	Again see above.

Done. Please see above.

  
	* The Check List says this project uses PAM and the man page shows:
	  /etc/pam.d/openwsman:

	  #%PAM-1.0
	  auth       required     pam_unix2.so    nullok
	  auth       required     pam_nologin.so
	  account    required     pam_unix2.so
	  password   required     pam_pwcheck.so  nullok
	  password   required     pam_unix2.so    nullok use_first_pass use_authtok
	  session    required     pam_unix2.so    none

	  None of these PAM modules seem to be delivered by this project and
are otherwise not part of OpenSolaris. 
      
Yes. The openwsman daemon can be configured to use PAM for 
authentication. By default, it only uses file based  authentication 
where in password files generated using htpasswd/htdigest are used.

The man page only shows a template pam.conf (the one which was available 
with the community source tarball). The pam.conf is currently not 
getting shipped as part of this package. The administrator has to create 
appropriate pam.conf in which the pam modules already delivered with 
OpenSolaris or any site specifc pam module could be made use of.

Please advice if man page needs to be modified to show an example which 
makes use of generic pam modules which are part of OpenSolaris.
    

	IMO if the project ships something on OpenSolaris, and it is
	has some configuration, it is incumbent on the project team 
	to correctly document how to configure the project on
	OpenSolaris.

Done. The man page now has an example for OpenSolaris mentioning the PAM modules available in OpenSolaris along with the example which was available for Linux.

	* The imported interfaces appear to show the use of OpenSSL.  IIRC,
it's use is contracted.  I don't find a mention of the contract.
  
      
Will check with Mark on the status and revert back.
    

	IMO, Before the case closes, this needs to be answered.
	IMO, Before the case integrates, any necessary contracts need
	to be out for signature.

Done. Have already got the contract PSARC/2003/500-31 signed.
I will check with Mark if he has updated the case materials to have the signed contract


	* The Check List says: "The openwsman daemon is sufficiently privileged
to authenticate the wsman client.  There will be no request for a password
change coming in over the wire via WS-Man." With Solaris Privileges, what
does "sufficiently privileged ..." mean? 
      
As specified in the method_context in the manifest file, the daemon will 
be started with uid and gid as root and with basic privileges.
    

	Why root?  Why is basic required?  If root why not no privs.

As mentioned above, the method_context has been removed and have added the Rights Profile and the required Authorizations for the same.

  
 If there is no password change over the wire, how exactly are passwords managed? 
      
The administrator will have to use htpasswd/htdigest to recreate the new 
password and install the same into the current simple/digest password 
files (default located in /etc/openwsman dir) .
    

	And how is write allowed to these commands to the /etc/openwsman
	directory?  Perhaps they should be in the same Rights Profile
	as the action and value authorizations.

Done.



When Openwsman daemon is configured to use PAM for authentication, 
openwsman pam plugin library in turn links to libpam  and makes use of 
function calls like pam_start(),  pam_authenticate() and pam_stop () to 
authenticate the user.
    

	Well, it should really be pam_start, pam_authenticate,
	pam_acct_mgmt, pam_end.

	The real point is above to have a proper pam.conf stack.
	Note also that the PAM service name is an exported interface
	and needs to be documented in the man page.  Presumably
	it is openwsman.

Yes. The authentication is happening in the same order as you have mentioned.
Have added proper pam.conf entries for OpenSolaris in the man page.


Thanks,
Srirama
--Boundary_(ID_STyC01Vpb1VxarZdnrYmPg)--