Will Fiveash wrote: > On Thu, Sep 11, 2008 at 11:45:35AM -0500, Nicolas Williams wrote: >> On Thu, Sep 11, 2008 at 06:26:40PM +0200, Mark Phalan wrote: >>> ???Was just doing some testing going through the different kinit and >>> PKCS11 opts to make sure everything is working ok. One of the options >>> which can be given as an argument is a path to a libpkcs11 library to >>> use (for e.g. -X PKCS11:module_name=/tmp/libpkcs11.so.1). >>> kinit is already linked against /usr/lib/libpkcs11.so.1. Won't bad >>> things happen if we dlopen() another libpkcs11.so and start trying to >>> call functions from it? Do direct bindings or anything get us anywhere >>> here? >>> I don't have a second libpkcs11.so on my system so and things don't seem >>> to blow up if a copy of libpkcs11.so is given as an argument to kinit. I >> Right, the linker is smart enough not to load the same object twice. >> >>> guess potentially the libpkcs11.so from opensc could be given as an >>> argument.. >> Yeah, things should blow up, though if you use direct bindingins when >> building OpenSC you may well avoid any problems. >> >>> Thoughts? >> Can we exclude that option in Solaris? OTOH, if we package and deliver >> OpenSC then we arguably should not exclude that option, but make it >> work instead. > > Perhaps I'm off base here but wouldn't it be better to add whatever > pkcs11/smart card functionality OpenSC has to the native Solaris pkcs11 > and just have kinit continue to use that. I'm not wild about adding > more options to krb utils if they aren't absolutely necessary. > > If we must support "-X PKCS11:module_name=/tmp/libpkcs11.so.1" then this > should be error tested carefully to make sure the user can't cause a > core dump and should get meaningful error messages.
OpenSC supports a number of smart cards, but not all of them. (It does not support CAC cards for example.) A vendor might provide their own pkcs11, to support their new card. They do for Windows at least. Mozilla gets around the single PKCS11 and lets you define multiple security modules, each of which is a pkcs11.so. Windows does it with CSPs from different vendors of which IdAlly and CoolKey provide provide CSPs that can call pkcs11, and thus OpenSC. Windows looks at the ATR, to determine what CSP to use. OpenSC does this too, but the interface to write a driver for a new card depends on the version of OpenSC. Mozilla/Firefoxwith NSS can use multiple security devices, which are pkcs11.so files. (I have used the opensc-pkcs11.so and the KX509 kpkcs11.so for example.) The issue with the Kerberos (pam_krb5) is there is a single module_name for a pkcs11. If a site has multiple cards, which require different pkcs11 implementations, which one do you list in the krb5.conf for pam? (OpenSC does support the cards we currently use at Argonne.) If your Solaris pkcs11 can load multiple pkcs11 modules, and determine which goes with which card, then one would not be tied to OpenSC, and your pkcs11 would serve the same functions as the Windows CSP, or Mozilla NSS. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
