Gary - Your issues seem to be around the documentation and the commitment levels. As has been mentioned numerous times, this is open-source code that is being brought into Solaris at the request of a large customer and the team needs to keep it as familiar as possible.
Also, as Darren mentioned, the Volatile level is necessary so we can address the name mapping issues later (currently under design). > 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? >> I don't have a problem with it, but I'm only an "intern". >> 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.) >> Whoever wrote the Linux docs incorrectly assumed that "smartcard" == "pkcs11 token". A smartcard is but one example of a pk11 token, it could also include the keystore on an SCA6000 or even a TPM (for example). Yes, the current docs on the website suck, but creating a whole new set of Solaris specific docs for an already existing open source project should not be a requirement for this project team. Perhaps the project team could drop an email to the open source maintainers with suggested changes to the docs at some point AFTER this project goes into Solaris along with the rest of the changes they have already agreed to try and give back. >> 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/) >> Is it common that we impose our auditing policies on all open source based projects for administering configuration files? We have lots of configuration files that have security implications that do not have auditable admin interfaces - ssh_config, sshd_config, krb5.conf, kdc.conf, just to name a few. >> * The introduction of administrative CLIs that appear to be intended >> to be entered interactively from a shell into /usr/lib/pam_pkcs11/. >> Isn't this just following the precedent from the Linux version? If so, then it should be OK since we are now trying to make Solaris more "Linux-Friendly". >> * 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. >> Putting it under SMF could be a follow-up RFE if the customer or someone else feels strongly that it would be beneficial, but I dont think it should be a barrier to approval for this project since they are trying hard to follow the current open source model and that is what the customer is expecting. If the customer has a team of admins that are used to the current model, it will only serve to annoy them if we move things to SMF and say "but, its Better this way!" >> * 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? >> It sounds like an overly-specific man page. Just remove the "SmartCard" part and it would probably be more accurate as "PKCS#11 Event Manager". This is definitely a nit. >> If the majority of the members are not concerned, I'll not stand in the >> way of the current proposal. >> IMO, this case has languished for too long and needs to move forward ASAP. -Wyllys
