Pete Batard wrote: >> Arnon Gilboa wrote: >> >>> As some of you may already know, Spice supports native USB device >>> redirection from client machine to VM (see http://www.spice-space.org). >>> For our Windows client we use libwdi for installing driver (currently >>> winusb) for the redirected devices. >>> Since we don't want the user to be asked for admin rights for each >>> install, we have written a dummy service for this job. >>> > > I had a quick look at your source, and as far as libwdi usage is > concerned, it looks good to me. > Hi Pete, > I see that you used wdi_register_logger() in an "Hack for wdi logging" > section (currenlty disabled). > Can you elaborate on the limitation you found there and if you would > like an enhancement of libwdi's logging facility? > I simply wanted wdi used by the service to log to a file instead of a pipe/stdout, so I gave it dummy args and patched about 5 lines in the libwdi logger code. Do you think my patch for that will be useful by others? > On 2012.04.25 18:47, Tim Roberts wrote: > >> The user still has to have admin rights to install your service, so from >> that standpoint I suppose it's not nefarious, >> > > I would agree with Tim too. If the user provides consent with regards to > running a service that aims at installing/removing a driver, then the > additional steps that the service will perform during the installation, > such as the adding of a one-time self-signed certificate in the security > store (which is conducted by libwdi and necessary to avoid prompts > during installation), should be considered as implicitly agreed on. > Right. > Also, since you are installing an Microsoft's WinUSB driver only, and > not altering the inf, there should be little security concerns with > regards to the driver installation itself. > Not altering the inf? libwdi is patching it. > Note however that, if your service binary is not digitally signed in a > way that end-users can verify, one might still see a security risk, as > it means end-users has no choice then but to trust that the binary they > downloaded wasn't altered from the one you intended whereas someone > could distribute a modified version of your service that performs > malicious activities. > I guess it can be Red Hat signed for upstream as well, as we do for other Spice windows binaries. > If you can, you may want to digitally sign any binary that requires to > be run elevated on Windows. > Sure. > But overall, the service and its usage in spice look very interesting. > I'll try to play with spice when I get a chance. > Play, I'm pretty sure you'll have fun. 10x, Arnon > Regards, > > /Pete > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > libusbx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libusbx-devel >
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libusbx-devel
