Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On 01/26/2011 11:29 AM, Alon Levy wrote: yes, the db is a directory name, treated as normal (can be absolute or relative to cwd, I don't check, just feed it to NSS). From qemu's point of view, it can be relative; but how does a libvirt user know what directory libvirt will be running in? Hence in the xml we might as well enforce that it be absolute, with no loss of functionality (and gui wrappers around libvirt can use typical file browser windows to allow relative browsing to locate such a directory). It defaults to /etc/pki/nssdb: (certutil needs an argument, we have it #defined: hw/ccid-card-emulated.c:#define CERTIFICATES_DEFAULT_DB /etc/pki/nssdb Okay, I'll add that same default to libvirt. Should we also have 'database' for the 'host' mode if we need one ? Yes, without it the usage of certificates is limited to the default certificate store, and if anyone wants to run multiple qemu's with different certificates they may want to put them into different dbs. Does qemu accept -device ccid-card-emulated,backend=nss-emulated,db=xyz? That is, if NSS is using a host USB device, then I don't see what the use is of providing a database directory in that case. I don't see a need to add a database subelement to mode='host' in the XML right now; we can leave that as a future enhancement to the XML without affecting this patch. I'm more worried that this patch does _not_ include anything that doesn't make sense, than I am about adding more later if we find we missed something. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On 01/26/2011 11:29 AM, Alon Levy wrote: yes, the db is a directory name, treated as normal (can be absolute or relative to cwd, I don't check, just feed it to NSS). It defaults to /etc/pki/nssdb: Hmm; given Osier's recent commit cc4447b to allow $HOME/.pki/libvirt to be tried first for non-root users, should the same logic be employed here (if nothing is explicitly requested, then favor $HOME/.pki/nssdb for non-root before falling back to /etc/pki/nssdb)? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Mon, Jan 31, 2011 at 04:33:46PM -0700, Eric Blake wrote: On 01/26/2011 11:29 AM, Alon Levy wrote: yes, the db is a directory name, treated as normal (can be absolute or relative to cwd, I don't check, just feed it to NSS). From qemu's point of view, it can be relative; but how does a libvirt user know what directory libvirt will be running in? Hence in the xml we might as well enforce that it be absolute, with no loss of functionality (and gui wrappers around libvirt can use typical file browser windows to allow relative browsing to locate such a directory). It defaults to /etc/pki/nssdb: (certutil needs an argument, we have it #defined: hw/ccid-card-emulated.c:#define CERTIFICATES_DEFAULT_DB /etc/pki/nssdb Okay, I'll add that same default to libvirt. Should we also have 'database' for the 'host' mode if we need one ? Yes, without it the usage of certificates is limited to the default certificate store, and if anyone wants to run multiple qemu's with different certificates they may want to put them into different dbs. Does qemu accept -device ccid-card-emulated,backend=nss-emulated,db=xyz? No, the db is only for backend=certificates, I thought that's what we were talking about. That is, if NSS is using a host USB device, then I don't see what the use is of providing a database directory in that case. It isn't, see above. I don't see a need to add a database subelement to mode='host' in the XML right now; we can leave that as a future enhancement to the XML without affecting this patch. I'm more worried that this patch does _not_ include anything that doesn't make sense, than I am about adding more later if we find we missed something. As long as you are talking about host mode not needing db I'm with you. But certificates mode (i.e. -device ccid-card-emulated,backend=certificates) does. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Mon, Jan 31, 2011 at 04:40:06PM -0700, Eric Blake wrote: On 01/26/2011 11:29 AM, Alon Levy wrote: yes, the db is a directory name, treated as normal (can be absolute or relative to cwd, I don't check, just feed it to NSS). It defaults to /etc/pki/nssdb: Hmm; given Osier's recent commit cc4447b to allow $HOME/.pki/libvirt to be tried first for non-root users, should the same logic be employed here (if nothing is explicitly requested, then favor $HOME/.pki/nssdb for non-root before falling back to /etc/pki/nssdb)? Sounds logical I guess. I should update the device to do the same on default (but of course if libvirt supplies a directory it would override the default). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Tue, Jan 25, 2011 at 05:36:54PM -0700, Eric Blake wrote: +dl + dtcodemode='host'/code/dt + ddThe simplest operation, where the hypervisor relays all + requests from the guest into direct access to the host's + smartcard via NSS. No other attributes or sub-elements are + required. However, in cases where extra permissions must be + granted to the hypervisor to access the host's smartcard device, + an optional codelt;source + dev='/path/to/smartcard'/gt;/code element is supported. + Also, see below about the use of an + optional codelt;addressgt;/code sub-element./dd Based on the mail about pcscd, we don't want a device path here after all. + dtcodemode='host-certificates'/code/dt + ddRather than requiring a smartcard to be plugged into the + host, it is possible to provide three files residing on the host + and containing NSS certificates. These certificates can be + generated via the command codecertutil -d /etc/pki/nssdb -x -t + CT,CT,CT -S -s CN=cert1 -n cert1/code, and the resulting three + files must be supplied as the content of each of + three codelt;certificategt;/code sub-elements. An + additional sub-element codelt;databasegt;/code can specify + an additional file to use as the database./dd What does the 'database' do ? This concept is somewhat specific to the NSS library afaict - other crypto libraries don't have a database like this. Should we also have 'database' for the 'host' mode if we need one ? Regards, Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Wed, Jan 26, 2011 at 12:25:06PM +, Daniel P. Berrange wrote: On Tue, Jan 25, 2011 at 05:36:54PM -0700, Eric Blake wrote: +dl + dtcodemode='host'/code/dt + ddThe simplest operation, where the hypervisor relays all + requests from the guest into direct access to the host's + smartcard via NSS. No other attributes or sub-elements are + required. However, in cases where extra permissions must be + granted to the hypervisor to access the host's smartcard device, + an optional codelt;source + dev='/path/to/smartcard'/gt;/code element is supported. + Also, see below about the use of an + optional codelt;addressgt;/code sub-element./dd Based on the mail about pcscd, we don't want a device path here after all. + dtcodemode='host-certificates'/code/dt + ddRather than requiring a smartcard to be plugged into the + host, it is possible to provide three files residing on the host + and containing NSS certificates. These certificates can be + generated via the command codecertutil -d /etc/pki/nssdb -x -t + CT,CT,CT -S -s CN=cert1 -n cert1/code, and the resulting three + files must be supplied as the content of each of + three codelt;certificategt;/code sub-elements. An + additional sub-element codelt;databasegt;/code can specify + an additional file to use as the database./dd What does the 'database' do ? This concept is somewhat specific to the NSS library afaict - other crypto libraries don't have a database like this. Should we also have 'database' for the 'host' mode if we need one ? Yes, without it the usage of certificates is limited to the default certificate store, and if anyone wants to run multiple qemu's with different certificates they may want to put them into different dbs. It is currently (well, there is only one backend currently, speaking tech wise certificates and emulated both use NSS) NSS specific, but I think winscard (started investigating that) also has some relevant concept. True that it might not fit. Still I think it's more useful with it. Regards, Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Wed, Jan 26, 2011 at 05:49:36PM +0200, Alon Levy wrote: On Wed, Jan 26, 2011 at 12:25:06PM +, Daniel P. Berrange wrote: On Tue, Jan 25, 2011 at 05:36:54PM -0700, Eric Blake wrote: +dl + dtcodemode='host'/code/dt + ddThe simplest operation, where the hypervisor relays all + requests from the guest into direct access to the host's + smartcard via NSS. No other attributes or sub-elements are + required. However, in cases where extra permissions must be + granted to the hypervisor to access the host's smartcard device, + an optional codelt;source + dev='/path/to/smartcard'/gt;/code element is supported. + Also, see below about the use of an + optional codelt;addressgt;/code sub-element./dd Based on the mail about pcscd, we don't want a device path here after all. + dtcodemode='host-certificates'/code/dt + ddRather than requiring a smartcard to be plugged into the + host, it is possible to provide three files residing on the host + and containing NSS certificates. These certificates can be + generated via the command codecertutil -d /etc/pki/nssdb -x -t + CT,CT,CT -S -s CN=cert1 -n cert1/code, and the resulting three + files must be supplied as the content of each of + three codelt;certificategt;/code sub-elements. An + additional sub-element codelt;databasegt;/code can specify + an additional file to use as the database./dd What does the 'database' do ? This concept is somewhat specific to the NSS library afaict - other crypto libraries don't have a database like this. Should we also have 'database' for the 'host' mode if we need one ? Yes, without it the usage of certificates is limited to the default certificate store, and if anyone wants to run multiple qemu's with different certificates they may want to put them into different dbs. It is currently (well, there is only one backend currently, speaking tech wise certificates and emulated both use NSS) NSS specific, but I think winscard (started investigating that) also has some relevant concept. True that it might not fit. Still I think it's more useful with it. What does QEMU/NSS do with the certificate database ? Is it a readonly database, or does QEMU/NSS also write to this ? I'm wondering why we need to specify x509 certificates, as well as the certificate database ? Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Wed, Jan 26, 2011 at 04:03:44PM +, Daniel P. Berrange wrote: On Wed, Jan 26, 2011 at 05:49:36PM +0200, Alon Levy wrote: On Wed, Jan 26, 2011 at 12:25:06PM +, Daniel P. Berrange wrote: On Tue, Jan 25, 2011 at 05:36:54PM -0700, Eric Blake wrote: +dl + dtcodemode='host'/code/dt + ddThe simplest operation, where the hypervisor relays all + requests from the guest into direct access to the host's + smartcard via NSS. No other attributes or sub-elements are + required. However, in cases where extra permissions must be + granted to the hypervisor to access the host's smartcard device, + an optional codelt;source + dev='/path/to/smartcard'/gt;/code element is supported. + Also, see below about the use of an + optional codelt;addressgt;/code sub-element./dd Based on the mail about pcscd, we don't want a device path here after all. + dtcodemode='host-certificates'/code/dt + ddRather than requiring a smartcard to be plugged into the + host, it is possible to provide three files residing on the host + and containing NSS certificates. These certificates can be + generated via the command codecertutil -d /etc/pki/nssdb -x -t + CT,CT,CT -S -s CN=cert1 -n cert1/code, and the resulting three + files must be supplied as the content of each of + three codelt;certificategt;/code sub-elements. An + additional sub-element codelt;databasegt;/code can specify + an additional file to use as the database./dd What does the 'database' do ? This concept is somewhat specific to the NSS library afaict - other crypto libraries don't have a database like this. Should we also have 'database' for the 'host' mode if we need one ? Yes, without it the usage of certificates is limited to the default certificate store, and if anyone wants to run multiple qemu's with different certificates they may want to put them into different dbs. It is currently (well, there is only one backend currently, speaking tech wise certificates and emulated both use NSS) NSS specific, but I think winscard (started investigating that) also has some relevant concept. True that it might not fit. Still I think it's more useful with it. What does QEMU/NSS do with the certificate database ? Is it a readonly database, or does QEMU/NSS also write to this ? I'm wondering why we need to specify x509 certificates, as well as the certificate database ? The cert1/cert2/cert3 names are only internal references in that db, they don't have a global meaning (i.e. it isn't filenames or any other type of uri). Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On 01/26/2011 11:09 AM, Alon Levy wrote: What does QEMU/NSS do with the certificate database ? Is it a readonly database, or does QEMU/NSS also write to this ? I'm wondering why we need to specify x509 certificates, as well as the certificate database ? The cert1/cert2/cert3 names are only internal references in that db, they don't have a global meaning (i.e. it isn't filenames or any other type of uri). That changes things in my implementation. That means that cert1/cert2/cert3 do not need _any_ SELinux labeling, because they are not files in the file system (just names within a database); furthermore, since they are not files, my documentation efforts of calling them out as absolute files in the docs needs tweaking. Meanwhile, the database _does_ need SELinux labeling (and I'm assuming here that the database argument, if provided, must be an absolute path to the actual file containing the database of the three certificate names). What does the database default to if you omit it from the qemu command line? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 1/5] smartcard: add XML support for smartcard device
On Wed, Jan 26, 2011 at 11:20:50AM -0700, Eric Blake wrote: On 01/26/2011 11:09 AM, Alon Levy wrote: What does QEMU/NSS do with the certificate database ? Is it a readonly database, or does QEMU/NSS also write to this ? I'm wondering why we need to specify x509 certificates, as well as the certificate database ? The cert1/cert2/cert3 names are only internal references in that db, they don't have a global meaning (i.e. it isn't filenames or any other type of uri). That changes things in my implementation. That means that cert1/cert2/cert3 do not need _any_ SELinux labeling, because they are not files in the file system (just names within a database); furthermore, since they are not files, my documentation efforts of calling them out as absolute files in the docs needs tweaking. Meanwhile, the database _does_ need SELinux labeling (and I'm assuming here that the database argument, if provided, must be an absolute path to the actual file containing the database of the three certificate names). What does the database default to if you omit it from the qemu command line? Sorry for the double work. I wasn't revieing the patches because I assumed it would be too much work, and didn't catch the point where you thought they were filenames. I'll fix that - I'll review the next set of patches ;) yes, the db is a directory name, treated as normal (can be absolute or relative to cwd, I don't check, just feed it to NSS). It defaults to /etc/pki/nssdb: (certutil needs an argument, we have it #defined: hw/ccid-card-emulated.c:#define CERTIFICATES_DEFAULT_DB /etc/pki/nssdb ) $ certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Alon3Cu,Cu,Cu Alon2Cu,Cu,Cu Alon1Cu,Cu,Cu $ ls /etc/pki/nssdb cert8.db cert9.db key3.db key4.db pkcs11.txt secmod.db -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
