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
