[kmf-discuss] restart of PSARC/2006/283 Certificate & PKCS#11 PAM module

[Huie-Ying Lee]

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