I have not seen a response to Gary's note. What is the status of this case?
-- mark Gary Winiger wrote: > I've been struggling how to make my comments largely architectural > and lead to convergence. It seems to me that I've been missing the > boat on being clear. > > My primary concern lies with the completeness of the administrative > documentation for Solaris and the stability of the interfaces. I've > said this publically and privately more than once during this case. > As I understand this project, it is intended to be a layer of the Solaris > Core replacement for pam_smartcard(5). Though, not there yet because of > missing infrastructure. Yet, all this case's components commitment levels > appear to be Volatile and the details of the administrative documentation > that the spec points to is on the community web site: > www.opensc-project.org/pam_pkcs11 > The materials pam_pcks11(5) man page seems to imply that will be > cloned in /usr/share/doc/pam_pkcs11/* with really no change and > delivered out of a separate package. While this is not part of the > materials, it does address keeping documentation and code in sync that > was a concern when the website was to be the definitive document. > Does the majority of the committee have problems with a seemingly Volatile > interface being a core component of system authentication? > Not having the proposed .../doc/pam_pkcs11/* as part of the materials, > I wonder if the user manual I've found on the website is really in the best > for Solaris administration as it appears to me to be pretty exclusively aimed > at Linux in describing configuration for pam_pkcs11. It also appears to > strongly imply smartcard. (Which the case log claims this case is not to > be about.) > > Other lesser concerns include: > * The spec's frequent use of "A user" for performing configuration. > * The introduction of new /etc files that seem security relevant > with no auditable administrative interface. (See the Solaris > Audit policy: > http://opensolaris.org/os/community/arc/policies/audit-policy/) > * The introduction of administrative CLIs that appear to be intended > to be entered interactively from a shell into /usr/lib/pam_pkcs11/. > * The introduction of an administrative CLI (shell script) that > appears to be intended to be entered interactively from a shell > in /etc/security/pam_pkcs11/ with a .sh suffix. > * The lack of Rights Profiles if the CLIs require any special "rights" > to properly execute. At least pkcs11_eventmgr(1) seems to > be a service that would fit under SMF, though there seems to be > no mention of SMF. See below for more on pkcs11_eventmgr. > * The seemingly accurate example in the spec of a login dialogue > that says: > "Please insert your smart card or enter your username." > (Nit, I presume this is a PAM_PROMPT_ECHO_ON message type. Does > it meet the PAM Policy relative to localization? See > http://opensolaris.org/os/community/arc/policies/PAM/) > * The pam_pkcs11(5) man page primarily refers to > www.opensc-project.org/pam_pkcs11/pam_pkcs11.html > which presently replies: > Error: Not Found > I would have expected a SEE ALSO of some section is docs.sun.com. > http://docs.sun.com/app/docs/doc/806-7010/intro.smartadmin-34?l=en&a=view&q=smartcard > equivalent. > * Nit: pam_pkcs11(5) shouldn't list command and man path names > under the FILES: section. > * Nit: pkcs11_eventmgr(1) claims "SmartCard PKCS#11 Event Manager" > If this is true, and pam_pkcs11(5) doesn't support smartcards > with this project, is the man page wrong, or should this > CLI/man page not be delivered until the pam_smartcard(5) > replacement project is integrated? > > If the majority of the members are not concerned, I'll not stand in the > way of the current proposal. > > Gary.. >
