Re: [Spice-devel] Help with SmartCards and XSpice
Alright, so I'm starting in on this. The plan is, as we discussed, for the spiceqxl_drv to create a fifo and relay the smart card messages through that. A new program, spice-ccid, will read those messages, and exchange the appropriate protocol with pcscd, which should provide it through to whatever application needs it. (I've written a dummy ccid driver, and it does all seem to work fine). First question: where should spice-ccid live? Should that be part of xf86-video-qxl? I can try asking the pcsclite folks if they'll take it; no idea how they'll respond to that one. Anyone have a strong opinion? Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
On 08/06/2014 06:14 PM, Jeremy White wrote: >>> And, finally, if that's all right - on to the next question: where >>> should spiceccid fit in the XSpice stack? Should it be part of the Xorg >>> driver? Should it be a vd_agent process? >> >> I'm not sure - I was thinking a third part, this time it's a bit more >> complicated, basically having a pcscd driver that would only be used by >> specific clients (i.e. processes, apps running presumably by the user >> controlling the Xspice instance). Usage scenario I guess is: >> 1. user launches Xspice (via some control interface) >> 2. user starts smartcard using app (i.e. firefox) >> 3. firefox connects to smartcard via pcscd, pcscd recognized this is >> supposed to go to the spice-ccid driver (to the *specific* one - you >> presumably have more then one instance of Xspice with different clients >> and hence smartcard hardware/credentials connected). You could use some >> environment variable, or perhaps having more then one instance of pcscd >> - that would make things simpler at the pcscd level, i.e. it could use a >> config file running only one driver, spice-ccid, with the correct unix >> domain socket connecting back to Xspice (spiceqxl_drv.so). > > Ah, okay, you're ahead of me. I hadn't gotten quite that far yet, but > your thought process seems sound to me. > > Your thinking seems to suggest you feel the hook should be another fifo > out of spiceqxl_drv.so. That would certainly be the easiest approach > for me to take, so I have a built in desire to go that way. But I worry > about complicating that driver. > > Why not route it through the vd_agent? vd_agent communicates with spiceqxl_drv.so via a pipe (or two? I forget - uinput and the vdagent protocol I mean). This would require one of 1. extending vd_agent protocol with the smartcard channel messages 2. using another pipe with smartcard channel messages And *then* you add a pipe / some other way of communicating from vd_agent to the pcscd driver (maybe you make the vdagent the driver, so it's loaded by pcscd.. no, doesn't sound like a good idea). > > Cheers, > > Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
And, finally, if that's all right - on to the next question: where should spiceccid fit in the XSpice stack? Should it be part of the Xorg driver? Should it be a vd_agent process? I'm not sure - I was thinking a third part, this time it's a bit more complicated, basically having a pcscd driver that would only be used by specific clients (i.e. processes, apps running presumably by the user controlling the Xspice instance). Usage scenario I guess is: 1. user launches Xspice (via some control interface) 2. user starts smartcard using app (i.e. firefox) 3. firefox connects to smartcard via pcscd, pcscd recognized this is supposed to go to the spice-ccid driver (to the *specific* one - you presumably have more then one instance of Xspice with different clients and hence smartcard hardware/credentials connected). You could use some environment variable, or perhaps having more then one instance of pcscd - that would make things simpler at the pcscd level, i.e. it could use a config file running only one driver, spice-ccid, with the correct unix domain socket connecting back to Xspice (spiceqxl_drv.so). Ah, okay, you're ahead of me. I hadn't gotten quite that far yet, but your thought process seems sound to me. Your thinking seems to suggest you feel the hook should be another fifo out of spiceqxl_drv.so. That would certainly be the easiest approach for me to take, so I have a built in desire to go that way. But I worry about complicating that driver. Why not route it through the vd_agent? Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
On 08/05/2014 05:33 PM, Jeremy White wrote: > Thanks! > > I'm going to mostly repeat what I think you just said to make sure I > understand you; please correct me if I get it wrong. > >> Yes. But just note that spice-server doesn't do anything except move >> bytes around. The actual protocols involved are: >> >> qemu: ccid protocol: usb smartcard reader >> spice-client via libcacard: smartcard > > Ah, okay; so Spice just relays bits from libcacard, it doesn't interpret > them in any way. Makes sense. > >> >> There are a few things you can do: >> 1. same components, minus usb bus >> nss-libcacard-APDU-[:removed: ccid_device]-[:removed: usb >> bus]-[:removed: usb bus driver]-[:new: spiceccid pcsc >> module]-pcscd-pam_pkcs11/coolkey > > Okay, I think that lines up with some further research I did. That is, > it seems like a good approach appears to be to write a driver to > interface with pcsc-lite (e.g. a bundle to go into > /usr/lib64/pcsc/drivers). I think that would then make the flow > something like this: > > client hardware <--> spice-gtk (using libcacard library) > spice-gtk <--> spice-server (spice protocol) > spice-server <--> new spiceccid module > (unknown protocol, probably libcacard influenced) > spiceccid <--> pcsc-lite.so (driver/bundle interface) > pcsc-lite then connects to applications (e.g. pam) as usual > > That seem about right? > >> 2. new protocol - I guess you ruled that out already. > > I didn't even consider it; I just imagined that reusing the existing > channels was the smart approach. Did I miss a better path by thinking > inside the box? I don't know - I haven't considered it in any amount of detail, I was just pointing out the obvious I guess, sorry. I meant simply that if your aim was (which clearly it isn't now) to abstract at the PAM/Credential (might not be the same thing) level you could tailor a protocol for that. > >> 3. pam modlue consuming APDUs from card - what you proposed - same as 1 >> but using a pam module to consume the APDUs. > > Yeah, I think approach #1 is better. > > In fact, it looks like we could hook at many points in the stack; we > could hook at the pam level, at the coolkey level, the pcsc-lite level, > and potentially even at the ccid level (e.g. below ccid). But my (still > naive and limited) instincts suggest that we want a peer to the ccid > module, which is what I understand #1 to be. > > And, finally, if that's all right - on to the next question: where > should spiceccid fit in the XSpice stack? Should it be part of the Xorg > driver? Should it be a vd_agent process? I'm not sure - I was thinking a third part, this time it's a bit more complicated, basically having a pcscd driver that would only be used by specific clients (i.e. processes, apps running presumably by the user controlling the Xspice instance). Usage scenario I guess is: 1. user launches Xspice (via some control interface) 2. user starts smartcard using app (i.e. firefox) 3. firefox connects to smartcard via pcscd, pcscd recognized this is supposed to go to the spice-ccid driver (to the *specific* one - you presumably have more then one instance of Xspice with different clients and hence smartcard hardware/credentials connected). You could use some environment variable, or perhaps having more then one instance of pcscd - that would make things simpler at the pcscd level, i.e. it could use a config file running only one driver, spice-ccid, with the correct unix domain socket connecting back to Xspice (spiceqxl_drv.so). > > Cheers, > > Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
Thanks! I'm going to mostly repeat what I think you just said to make sure I understand you; please correct me if I get it wrong. Yes. But just note that spice-server doesn't do anything except move bytes around. The actual protocols involved are: qemu: ccid protocol: usb smartcard reader spice-client via libcacard: smartcard Ah, okay; so Spice just relays bits from libcacard, it doesn't interpret them in any way. Makes sense. There are a few things you can do: 1. same components, minus usb bus nss-libcacard-APDU-[:removed: ccid_device]-[:removed: usb bus]-[:removed: usb bus driver]-[:new: spiceccid pcsc module]-pcscd-pam_pkcs11/coolkey Okay, I think that lines up with some further research I did. That is, it seems like a good approach appears to be to write a driver to interface with pcsc-lite (e.g. a bundle to go into /usr/lib64/pcsc/drivers). I think that would then make the flow something like this: client hardware <--> spice-gtk (using libcacard library) spice-gtk <--> spice-server (spice protocol) spice-server <--> new spiceccid module (unknown protocol, probably libcacard influenced) spiceccid <--> pcsc-lite.so (driver/bundle interface) pcsc-lite then connects to applications (e.g. pam) as usual That seem about right? 2. new protocol - I guess you ruled that out already. I didn't even consider it; I just imagined that reusing the existing channels was the smart approach. Did I miss a better path by thinking inside the box? 3. pam modlue consuming APDUs from card - what you proposed - same as 1 but using a pam module to consume the APDUs. Yeah, I think approach #1 is better. In fact, it looks like we could hook at many points in the stack; we could hook at the pam level, at the coolkey level, the pcsc-lite level, and potentially even at the ccid level (e.g. below ccid). But my (still naive and limited) instincts suggest that we want a peer to the ccid module, which is what I understand #1 to be. And, finally, if that's all right - on to the next question: where should spiceccid fit in the XSpice stack? Should it be part of the Xorg driver? Should it be a vd_agent process? Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
On 07/25/2014 12:01 AM, Jeremy White wrote: >>> I think I have a tentative, but sufficient grasp of how the Smart Card >>> stuff flows from the client into the server. It's not quite as clear >>> how the server bridges it into qemu, but I think I have the gist of it. >>> >>> However, that doesn't work for XSpice sessions. >> >> I'm not sure why it shouldn't. The qemu portion simply forwards the ccid >> APDU's from the host. Spice has libcaccard which translates the CAC >> requests into calls against your PKCS #11 token on your client side. > > Alright, my ignorance is showing; perhaps I need to understand the qemu > path better. > > In what I think of a typical use case, you have a client with a smart > card reader attached. Let's say that is a Fedora 20 box. Then you have > a host system which runs qemu to start a guest VM; let's say the host > system is RHEL and the guest VM is Fedora RawHide. > > My understanding is that the client (essentially spice-gtk) interacts > with the physical hardware, and uses libcacard to put the smartcard data > onto the Spice smartcard channel. > > This is passed over the spice channel into qemu (running on the host), > which uses the spice server calls to decode the data, and then it writes > the data to a virtual character device that appears in the guest as a > USB CCID device. RawHide detects that and treats it a 'real' hardware > device. > > How am I doing so far? Is that about right? Yes. But just note that spice-server doesn't do anything except move bytes around. The actual protocols involved are: qemu: ccid protocol: usb smartcard reader spice-client via libcacard: smartcard > > In the XSpice case, we have no qemu. Instead, the host system runs Xorg > against what is a virtual framebuffer, and runs the xf86-video-qxl xorg > driver. > > In my use case, I've got Xorg running, with spice, and I'm just about to > launch xdm. I'd really like to have a smartcard, if available, be part > of the pam stack prior to launching xdm, so that it can be used by pam. > > Given that, how do you expect the smartcard data to flow into that Xorg > session?I imagine that either the qxl driver, or a different utility > (e.g. vd_agent) would be required in order to relay the smartcard data > from the channel and into the pam stack. Is there something I'm missing? You are fine with only apps using pam_pkcs11 (i.e. anything using pam) using the smartcard? if so your direction makes sense. But the protocol is very low level for that - it passes what the CCID expects to get from the card. In the guest there is a CCID driver (there are multiple, but for coolkey I tested pcsclite http://pcsclite.alioth.debian.org/ccid.html ), which is consumed by coolkey via winscard.h and uses pcscd. There are a few things you can do: 1. same components, minus usb bus nss-libcacard-APDU-[:removed: ccid_device]-[:removed: usb bus]-[:removed: usb bus driver]-[:new: spiceccid pcsc module]-pcscd-pam_pkcs11/coolkey 2. new protocol - I guess you ruled that out already. 3. pam modlue consuming APDUs from card - what you proposed - same as 1 but using a pam module to consume the APDUs. > >> >>> >>> It looks to me that this should be possible. My research suggests >>> that pam_pkcs11 is pluggable, and that it should be possible to write >>> a module that would receive the cert information. >> pam_pkcs11 uses plugable PKCS #11 modules (which also work in firefox >> and other NSS applications). You would have to install this module in >> your guest, however. I think redirecting the CCID USB data would be >> easier, though. > > Yeah, I saw that ccid was also pluggable, and I begin to see why that > would be a better layer to plug into. (Saves me the hassle of parsing > the cert data, right?) > > > Cheers, > > Jeremy > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
I think I have a tentative, but sufficient grasp of how the Smart Card stuff flows from the client into the server. It's not quite as clear how the server bridges it into qemu, but I think I have the gist of it. However, that doesn't work for XSpice sessions. I'm not sure why it shouldn't. The qemu portion simply forwards the ccid APDU's from the host. Spice has libcaccard which translates the CAC requests into calls against your PKCS #11 token on your client side. Alright, my ignorance is showing; perhaps I need to understand the qemu path better. In what I think of a typical use case, you have a client with a smart card reader attached. Let's say that is a Fedora 20 box. Then you have a host system which runs qemu to start a guest VM; let's say the host system is RHEL and the guest VM is Fedora RawHide. My understanding is that the client (essentially spice-gtk) interacts with the physical hardware, and uses libcacard to put the smartcard data onto the Spice smartcard channel. This is passed over the spice channel into qemu (running on the host), which uses the spice server calls to decode the data, and then it writes the data to a virtual character device that appears in the guest as a USB CCID device. RawHide detects that and treats it a 'real' hardware device. How am I doing so far? Is that about right? In the XSpice case, we have no qemu. Instead, the host system runs Xorg against what is a virtual framebuffer, and runs the xf86-video-qxl xorg driver. In my use case, I've got Xorg running, with spice, and I'm just about to launch xdm. I'd really like to have a smartcard, if available, be part of the pam stack prior to launching xdm, so that it can be used by pam. Given that, how do you expect the smartcard data to flow into that Xorg session?I imagine that either the qxl driver, or a different utility (e.g. vd_agent) would be required in order to relay the smartcard data from the channel and into the pam stack. Is there something I'm missing? It looks to me that this should be possible. My research suggests that pam_pkcs11 is pluggable, and that it should be possible to write a module that would receive the cert information. pam_pkcs11 uses plugable PKCS #11 modules (which also work in firefox and other NSS applications). You would have to install this module in your guest, however. I think redirecting the CCID USB data would be easier, though. Yeah, I saw that ccid was also pluggable, and I begin to see why that would be a better layer to plug into. (Saves me the hassle of parsing the cert data, right?) Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
On 07/22/2014 12:41 PM, Jeremy White wrote: I'm hoping to get some guidance / clue bats / shock and horror in implementing Smart Card support for XSpice clients. I think I have a tentative, but sufficient grasp of how the Smart Card stuff flows from the client into the server. It's not quite as clear how the server bridges it into qemu, but I think I have the gist of it. However, that doesn't work for XSpice sessions. I'm not sure why it shouldn't. The qemu portion simply forwards the ccid APDU's from the host. Spice has libcaccard which translates the CAC requests into calls against your PKCS #11 token on your client side. It looks to me that this should be possible. My research suggests that pam_pkcs11 is pluggable, and that it should be possible to write a module that would receive the cert information. pam_pkcs11 uses plugable PKCS #11 modules (which also work in firefox and other NSS applications). You would have to install this module in your guest, however. I think redirecting the CCID USB data would be easier, though. So presuming I have a module hook ready to receive certs, the next question is how to get them there. The way that 'feels' right to me is to extend the Linux vd_agent to receive the smart card traffic, and so it is then vd_agent that communicates with my hypothetical pam hook. The alternate would be to put it into the spiceqxl_drv.so. That seems less ideal, but would probably be less code, and wouldn't require messing with the vdagent protocol. Thoughts? Comments? Clue bats? Thanks, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel smime.p7s Description: S/MIME Cryptographic Signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Help with SmartCards and XSpice
I'm hoping to get some guidance / clue bats / shock and horror in implementing Smart Card support for XSpice clients. I think I have a tentative, but sufficient grasp of how the Smart Card stuff flows from the client into the server. It's not quite as clear how the server bridges it into qemu, but I think I have the gist of it. However, that doesn't work for XSpice sessions. It looks to me that this should be possible. My research suggests that pam_pkcs11 is pluggable, and that it should be possible to write a module that would receive the cert information. So presuming I have a module hook ready to receive certs, the next question is how to get them there. The way that 'feels' right to me is to extend the Linux vd_agent to receive the smart card traffic, and so it is then vd_agent that communicates with my hypothetical pam hook. The alternate would be to put it into the spiceqxl_drv.so. That seems less ideal, but would probably be less code, and wouldn't require messing with the vdagent protocol. Thoughts? Comments? Clue bats? Thanks, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
