On Wed, Dec 12, 2012 at 12:31 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > Hey, Hi, > 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. Only if the app chooses to do so (fwiw, Boxes doesn't do that). Apps using libosinfo rely on the data provided for setting up many different things so if I'd get worried about DB being compromised, drivers isn't the only problem we have. Especially the install scripts can do whatever they want on your VM. While I might not be as worried about local DB getting compromised as much as you, I will share the concern when we execute our plan to have the whole DB available online and apps using that directly. > 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. I should have explained better. The main rationale for checksums was to check if file got corrupted or not during download. #1 is more of a side-affect. TBH, security wasn't my concern with these patches. >We need to use something > different than md5 though if we want to rely on that as this has known > collision vulnerabilities. Depends on the maximum size of files we expect, doesn't it? > 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). Yeah, GPG signing sounds like a good idea to me. I'll look into 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). True. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
