Re: [PATCHv3 0/5] smartcard: round 3

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

 



On Wed, Jan 26, 2011 at 12:21:58PM +0000, Daniel P. Berrange wrote:
> On Wed, Jan 26, 2011 at 08:59:27AM +0200, Alon Levy wrote:
> > On Tue, Jan 25, 2011 at 05:36:53PM -0700, Eric Blake wrote:
> > > This series has hopefully taken into account all the feedback from v2
> > > (https://www.redhat.com/archives/libvir-list/2011-January/msg00608.html).
> > > 
> > > Major changes:
> > >  - enhance the XML to support optional ccid <controller> (missing
> > > controllers are added according to <address> elements) and optional
> > > <address> per smartcard (missing address assume the next available
> > > port on controller 0)
> > >  - enhance the XML to support an optional <source dev='/path'/> for
> > > host mode. For now, this path is only used in SELinux labeling; I
> > > suspect that this needs more work, since the point is that a single
> > > device in the host should be shared among the NSS implementation of
> > > multiple guests (so labeling the host device to belong to a single
> > > guest is wrong); but fixing it correctly requires a better
> > > understanding of what NSS actually needs to access, as well as
> > > possibly modifying qemu's smartcard implementation to take the
> > > host device either as a pathname or even as an already-opened fd.
> > 
> > I just remembered how NSS actually talks to cards. So basically if
> > you are using a physical card it will go through a TCP connection to
> > a local daemon called pcscd - I'm guessing that means no SELinux
> > labeling would be required? Does SELinux label sockets?
> 
> Yes, selinux labels *everything*.
> 
> > pcscd is a single instance, so wouldn't pose a problem for SELinux.
> > It uses libccid which is linked to libusb which does the actual
> > device open, so just pcscd needs the permissions for device access.
> 
> This will require a SELinux policy addition to allow QEMU to connect
> to the pcscd sockets. It isn't something we can solve in the libvirt
> security drivers unfortunately. It kind of sucks because we'd need
> a admin toggled boolean 'virt_use_smartcards' to allow access globally.
> Then again few people will ever use this mode of smartcard access
> anyway, so its not too bad.

Queue wisecrack.

> 
> Daniel

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]