Hey, On Wed, Dec 12, 2012 at 03:21:27AM +0200, Zeeshan Ali (Khattak) wrote: > These patches aims to provide applications a way to be able to verify the > integrity of driver files, which they'll typically be downloading over > unreliable networks. This series opens up some interesting questions... If I understand correctly, you want to check that the files that were downloaded didn't get corrupt during the download (or that they were not silently corrupted server-side, ..). However, what this does not address is checking if the driver we downloaded is legit. By 'legit', I mean making sure the library user actually downloaded the file we intended her to download when libosinfo told her to use 'http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/x86/viostor.sys' as the virtio-disk driver. There are various ways for a malicious user to return a different file from the one we intended (DNS hijacking, hacking zeenix.fedorapeople.org, ...). As these drivers are then automatically installed in the guest, a malicious file downloaded this way could do quite some nasty things. Let's call this issue #1. Another vector I'm worried about is the fact that by default we load database data from ~/.config/libosinfo/db after the system data. This can probably be abused by overriding Windows installation info and pointing it at drivers on a totally different server. I'll call this issue #2. Your patch series would address issue #1 as the file checksums will be hardcoded in the system libosinfo database. We need to use something different than md5 though if we want to rely on that as this has known collision vulnerabilities. This does not address #2. And even that validation will probably break once we add a way to download updates to the libosinfo database from the net as the db updates could be compromised in the same way, with the drivers URLS/sha256sum changed to point to malicious drivers. One way of addressing these issues would be to add GPG signatures alongside each file we want to download, and hardcoding the known keys in libosinfo binary. Other options could be to only validate DB updates in such a way, or to not allow install-scripts and related data to be overridden by the user/remote updates (didn't give a lot of thoughts to that). The reason I'm bringing that up now is that this seems to me more worrying than checking that the file was not corrupted doing download, and, depending on which way we want to go to solve these problems, the solution may be redundant with what this series does (ie checking that the files are legit would also guarantee that they were not corrupt during download). Thoughts? Christophe
Attachment:
pgp5Z0s9TaG7B.pgp
Description: PGP signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
