Anthony Scarpino wrote: > Douglas E. Engert wrote: >> Sun appears to be headed down the path of using /usr/lib/libpkcs11.so >> with Kerberos PKINIT as well as pam_pkcs11.so, and it was said >> opensc-pkcs11.so works with libpkcs11. So I wanted to try this for >> myself. >> >> I obtained a elfsign certificate from Sun and signed the opensc-pkcs11.so >> and installed it using cryptoadm install provider=..../opensc-pkcs11.so >> >> Using the opensc-0.11.6 and pcscd I have run into two related problems, >> and a problem where sshd (and dtlogin) will not run if the >> opensc-pkcs11.so >> is listed as a provider. >> >> Sun appears to expect C_GetMechaismList to return a list if there is a >> slot >> present, even if there is no token present. See the attached >> cryptoadmin.txt >> >> I think this is a bug in Sun's code. PKCS#11 2.01 and 2.20 say: >> "C_GetMechanismList is used to obtain a list of mechanism >> types supported by a token." >> >> If there is no token they should not ask for a list of mechanisms. Note >> that crytpoadm shows that there is no token present in the slot. > > In my opinion, this is just a bug in the OpenSC library and not in > cryptoadm. The above excerpt I believe applies to the OpenSC library > and not to something like cryptoadm. The library is responsible for the > mechanism list and if there is no token it should respond with nothing > in the mechanism list, not a core dump.
As I said below, I have submitted the fix for the segfault to OpenSC. and the test run was with the fix. The question is if a MechanismList is associated with a token, and there is not token present why is the Sun code requesting a Mechanism List? What is cryptoadmin doing? What is libpkcs11 doing with a null list? > > Having cryptoadm verify CKF_TOKEN_PRESENT is true would be a workaround, > but I feel that it's just hiding the issue.. > No it not. The issue is the Mechanisum List is for a token, not the slot so it should verify CKF_TOKEN_PRESENT. >> >> The above test was run with the following patch installed. >> >> OpenSC will show a slot is present if there is a reader, but >> will segfault if C_GetMechanismList is called for an unused >> virtual slot. I submitted to OpenSC ticket number #181 >> >> the attached slot.null.txt is a gdb trace of the Sun cryptoadm >> calling C_GetMechanisnList for the first of the virtual slots. >> There is a card in the reader using the first 4 slots. >> >> Note that sc_pkcs11_get_mechanism_list is called with p11card=0x0. >> Ticket #181 gets around this. >> >> >> I have not tracked down the sshd and login problems yet. >> I am assuming that is related to no mechanism list. > > Just a wild stab here.. If metaslot is enabled, it will retrieve a list > of mechanisms from all the providers. You may try disabling metaslot, > 'cryptoadm disable metaslot', to see if that helps.. > >> Note that sshd should not be using the console user's >> smartcard for any crypto! > > OpenSC and the smartcard are providers in PKCS#11. If it is providing > crypto to the system, it is available to be used. Granted no one would > ever want a smartcard to do the crypto ops, but there is nothing in > PKCS#11 to stop it.. > > Tony > > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
