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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090122/57312a62/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Openwsman-ARC-FOSS-Checklist.txt
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090122/57312a62/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Openwsman-ARC-onepager.txt
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090122/57312a62/attachment-0001.txt>

Reply via email to