Wyllys Ingersoll wrote: > > 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. > >
Right. I have actually started contacting the current open source maintainers and I will make sure to air our concerns about quality of document issues to them. >>> 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. I will remove the command and man path names undeer the FILES: section from the pam_pkcs11(5) man page. >>> * 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. > After careful investigation, I found the pkcs11_eventmgr command is actually not useful at all. I would like to remove it from the deliverables. > >>> 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 > Thanks, Huie-Ying
