> > 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?
> <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.
> 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.
>
> <method_context>
> <method_credential
> user='root'
> group='root'
> privileges='basic'
> />
> </method_context>
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..
