qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Virtual Smartcard GPG


From: Jakob Bohm
Subject: Re: [Qemu-discuss] Virtual Smartcard GPG
Date: Wed, 29 Apr 2015 18:20:52 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 29/04/2015 13:22, address@hidden wrote:
Hi. I am trying to get a virtual smartcard attached to a vm but I want it to use GPG instead of NSS. RedHat focuses on NSS because of PKCS#11 requirements and FIPS approval, but for most of the community its GPG that matters for smartcards.

Is is possible to use GPG on the host instead of NSS with virtual smartcards? Please document how or add support for it.

I don't know, I have not yet studied that feature.
However I have always been disappointed that the gnupg
code chose to invent its own smart card API rather than
using the standard PKCS#11 API.  Maybe (just maybe)
later versions of gnupg added support for using PKCS11
drivers.

As a datapoint, gnupg 1.4.10 seems to support accessing
non-usb card readers via pcsclite, as well as built in
support to access CCID card readers via libusb but
apparently not the use of pkcs11 card specific drivers.

Is using a virtual smartcard make the host less secure from a rogue vm? If there are bugs in GPG/NSS backend on the host can they be abused by untrusted code in the vm?

This is true for all emulated devices, no exceptions.
If the device emulation code in qemu (or worse, in the
KVM host kernel part) has a bug in checking arguments
received from the VM, this can be used to "escape from
VM" by anything using that device.

Sometimes (depending on the bug, not the design), such
bugs are only exploitable from the Guest Kernel mode
device driver, while in other cases such bugs can be
exploited from Guest user mode code.

For example (random guess), if the virtual smart card
feature is exposed to the Guest as a virtual USB CCID
card reader, then the ability to exploit any bugs in
it may be restricted to:

a) Anything allowed to access the virtual reader at the
PC/SC like API level.

b) Anything allowed to access the virtual reader at the
libusb API level.

c) Only from the actual kernel mode USB code in the Guest
kernel.

d) Nothing, if there is no bug.

Case d) is of cause the best case, a), the worst.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded




reply via email to

[Prev in Thread] Current Thread [Next in Thread]