Bug 1297533

Created attachment 1113651 [details]
cleaned RHEV Host sosreport

Created attachment 1113652 [details]
cleaned RHEV-M sosreport

Created attachment 1113653 [details]
remote-viewer deug log

Ran the following commands after connecting to the VM. Ran pkcs11_inspect to rule out BZ 1249116:

root /root]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 08e6:4433 Gemalto (was Gemplus) GemPC433-Swap
root /root]#


root /root]# pkcs11_inspect debug
DEBUG:pam_config.c:238: Using config file /etc/pam_pkcs11/pam_pkcs11.conf
DEBUG:pkcs11_lib.c:182: Initializing NSS ...
DEBUG:pkcs11_lib.c:192: Initializing NSS ... database=/etc/pki/nssdb
DEBUG:pkcs11_lib.c:210: ...  NSS Complete
DEBUG:pkcs11_inspect.c:69: loading pkcs #11 module...
DEBUG:pkcs11_lib.c:235: Looking up module in list
DEBUG:pkcs11_lib.c:238: modList = 0x2483460 next = 0x2492a60

DEBUG:pkcs11_lib.c:239: dllName= <null>

DEBUG:pkcs11_lib.c:238: modList = 0x2492a60 next = 0x0

DEBUG:pkcs11_lib.c:239: dllName= libcoolkeypk11.so

DEBUG:pkcs11_inspect.c:78: initialising pkcs #11 module...
DEBUG:pkcs11_inspect.c:95: no token available
root /root]# pkcs11_inspect debug
DEBUG:pam_config.c:238: Using config file /etc/pam_pkcs11/pam_pkcs11.conf
DEBUG:pkcs11_lib.c:182: Initializing NSS ...
DEBUG:pkcs11_lib.c:192: Initializing NSS ... database=/etc/pki/nssdb
DEBUG:pkcs11_lib.c:210: ...  NSS Complete
DEBUG:pkcs11_inspect.c:69: loading pkcs #11 module...
DEBUG:pkcs11_lib.c:235: Looking up module in list
DEBUG:pkcs11_lib.c:238: modList = 0x1dda4c0 next = 0x1de7a30

DEBUG:pkcs11_lib.c:239: dllName= <null>

DEBUG:pkcs11_lib.c:238: modList = 0x1de7a30 next = 0x0

DEBUG:pkcs11_lib.c:239: dllName= libcoolkeypk11.so

DEBUG:pkcs11_inspect.c:78: initialising pkcs #11 module...
DEBUG:pkcs11_inspect.c:95: no token available
root /root]#


root /root]# modutil -dbdir /etc/pki/nssdb/ -list

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS #11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services
        token: NSS Certificate DB

  2. CoolKey PKCS #11 Module
        library name: libcoolkeypk11.so
         slots: 1 slot attached
        status: loaded

         slot: Gemplus GemPC433 SL (1) 00 00
        token:
-----------------------------------------------------------
root /root]#

Error from remote-viewer debug log:

"GSpice-WARNING **: Failed to initialize smartcard"

The VM being used is knoxhrc0a0l1033.

Is coolkey installed on client side? The token must be first visible by the client, using nss (by default using /etc/pki/nssdb config database). Could you give "pkcs11_inspect debug" output run as a normal user in the client ? thanks

On windows, the nssdb location is CSIDL_COMMON_APPDATA\pki\nss, typically C:\Documents and Settings\username\Application Data\pki\nss.

The client system can see the token. They also tested the smartcard on a baremetal RHEL system just to verify that it worked with non-virt RHEL.

"GSpice-WARNING **: Failed to initialize smartcard"

shows that the client couldn't initilize, likely because it couldn't read the certificates. could you provide certutil.exe -d C:\Documents and Settings\username\Application Data\pki\nss -L -h all output?

moving to libcacard for further analysis

The directory where remote-viewer's nss expects nssdb is C:\ProgramData\pki\nssdb (a.k.a. C:\*\All Users\Application Data\pki\nssdb = %ALLUSERSAPPDATA%\pki\nssdb CSIDL_COMMON_APPDATA\pki\nssdb).

When using modutil -list on client*, you should see something in token: field of your pkcs#11 library analogous to this linux output:
  2. CoolKey PKCS #11 Module
	library name: libcoolkeypk11.so
	 slots: 1 slot attached
	status: loaded

	 slot: Gemalto PC Twin Reader 00 00
	token: spice qe                           # <---- here


* so: modutil -dbdir C:\ProgramData\pki\nssdb -list


note however that you may run into bug 917867 once you get your client configuration right, to verify, you can install windows CoolKey and see if it can share some card

From the 7.2 Release Notes:

QEMU-emulated CAC smart cards incompatible with ActivClient software

Currently, Common Access Card (CAC) smart cards emulated with QEMU are not accepted by ActivClient software. To work around this problem, disable the pcscd daemon, provision a Windows KVM guest, preconfigure it in the virt-viewer tool and select the USB redirection option, install the ActivClient software, and reboot the KVM guest. With this setup, ActivClient accepts the emulated CAC card. 

This seems very vague to me. Where are we disabling to pcsd daemon? On the Guest or the Client or both?

(In reply to Frank DeLorey from comment #22)
> From the 7.2 Release Notes:
> 
> QEMU-emulated CAC smart cards incompatible with ActivClient software

which is probably a reference to bug 917867 I mentioned in comment 20

> 
> Currently, Common Access Card (CAC) smart cards emulated with QEMU are not
> accepted by ActivClient software. To work around this problem, disable the
> pcscd daemon, provision a Windows KVM guest, preconfigure it in the
> virt-viewer tool and select the USB redirection option, install the
> ActivClient software, and reboot the KVM guest. With this setup, ActivClient
> accepts the emulated CAC card. 
> 
> This seems very vague to me. Where are we disabling to pcsd daemon? On the
> Guest or the Client or both?

The purpose of this procedure is to disable smart card in the client so that pcscd doesn't clam exclusive access to smart card reader in order to redirect the reader to the guest. This is an universal and reliable way to make smart card available to the guest but it won't be available in the client so if your customer uses smart card for authentication to both client system and guest system, it's not applicable to them.


Setting back needinfo as question from comment 19 was not answered.

It appears that the customer's problem is being caused by their use of ActivClient on their Windows 7 client system. So they have a client running Windows 7 with ActivClient and they are trying to shared the card with a RHEL guest which I believe will not work. It seems that if they are required to use ActivClient then the only choice they have is redirection and not shared use.

c:\Program Files\VirtViewer v0.6.0-34\bin>certutil.exe -d ..\etc\pki\nssdb -L -h all Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Press Enter, then enter PIN for "ActivIdentity ActivClient 1" on external device. ActivIdentity ActivClient 1:HAY.ROGER.XXXXXXX.XXXXXXXXXX's U.S. Government ID Certificate u,u,u ActivIdentity ActivClient 1:HAY.ROGER.XXXXXXX.XXXXXXXXXX's U.S. Government Signature Certificate u,u,u ActivIdentity ActivClient 1:HAY.ROGER.XXXXXXX.XXXXXXXXXX's U.S. Government Encryption Certificate u,u,u c:\Program Files\VirtViewer v0.6.0-34\bin

I think at this point there is nothing more that needs to be done as the BZ for the ActivClient use is closed as won't fix, so unless this customer's account team can come up with a business case I think Engineering's involvement is not needed. 

Thanks,

Frank

(In reply to Frank DeLorey from comment #25)
> It appears that the customer's problem is being caused by their use of
> ActivClient on their Windows 7 client system. So they have a client running
> Windows 7 with ActivClient and they are trying to shared the card with a
> RHEL guest which I believe will not work. It seems that if they are required
> to use ActivClient then the only choice they have is redirection and not
> shared use.
> 

That may be end result (because of bug 917867 or maybe unavailability of ActivClient middleware for Linux guest) but I don't think we're there yet...

> c:\Program Files\VirtViewer v0.6.0-34\bin>certutil.exe -d ..\etc\pki\nssdb
> -L -h all Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Press
> Enter, then enter PIN for "ActivIdentity ActivClient 1" on external device.
> ActivIdentity ActivClient 1:HAY.ROGER.XXXXXXX.XXXXXXXXXX's U.S. Government
> ID Certificate u,u,u ActivIdentity ActivClient
> 1:HAY.ROGER.XXXXXXX.XXXXXXXXXX's U.S. Government Signature Certificate u,u,u
> ActivIdentity ActivClient 1:HAY.ROGER.XXXXXXX.XXXXXXXXXX's U.S. Government
> Encryption Certificate u,u,u c:\Program Files\VirtViewer v0.6.0-34\bin

... because your customer keeps using wrong nssdb. The important nssdb is in C:\ProgramData\pki\nssdb as I already wrote.

> 
> I think at this point there is nothing more that needs to be done as the BZ
> for the ActivClient use is closed as won't fix,

That's bz for RHEL6 host which is not going to get anything but important bugfixes past 6.8. BZ for el7 is still open...

> so unless this customer's
> account team can come up with a business case

... waiting for such a bussiness case.

> I think Engineering's
> involvement is not needed. 
> 
> Thanks,
> 
> Frank

So the directory is effectively hardcoded in libcacard [1]:
#ifndef _WIN32
        path = g_strdup("/etc/pki/nssdb");
#else
        if (g_get_system_config_dirs() == NULL ||
            g_get_system_config_dirs()[0] == NULL) {
            return VCARD_EMUL_FAIL;
        }

        path = g_build_filename(
            g_get_system_config_dirs()[0], "pki", "nssdb", NULL);
#endif

as g_get_system_config_dirs()[0] returns CSIDL_COMMON_APPDATA on Windows [2] - which means C:\ProgramData on Windows 7 and newer ("C:\Documents and Settings\All Users\Application Data" on XP). So setting up nssdb at any different location is bound to fail.

[1] https://cgit.freedesktop.org/spice/libcacard/tree/src/vcard_emul_nss.c#n924
    - the same code is in qemu tree in currently packaged versions
[2] https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-system-config-dirs

Update from the customer:

I was able to get it to work using the following

Copied C:\Program Files\VirtViewer v0.6.0-34\etc\pki\nssdb to c:\ProgramData\pki\nssdb 

# Added active client to nssdb using the following:
modutil -add "CAC" -libfile acpkcs211.dll -dbdir c:\ProgramData\pki\nssdb 


Though I quickly found out that there is no way to specify which of my two smartcard readers it uses but I was able to see the token finally.


ActivClient is used on the Windows workstation (client) and libcoolkey on (guest).

This is not a bug just a requirement for the location of the nssdb.