On Wed, Dec 12, 2012 at 5:43 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > On Wed, Dec 12, 2012 at 04:41:03PM +0200, Zeeshan Ali (Khattak) wrote: >> 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). > > Are you sure? osinfo_loader_process_default_path() loads user data, and > Boxes calls this. Then I remembered wrong. Thing is that we load our (Boxes) custom logos db explicitly so that confused me.. >> > 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. > > Yes, this was my feeling as well (that they were not aimed at security). > However these patches probably overlap with making this stuff more secure, > and depending on how we choose to achieve this, they may be redundant/need > adjustments, that's why I'm wondering what we want to do there. After talking to Daniel on IRC about this, I agree with him that properly addressing all security issues would be pain and we really have better things to do right now. Checksums already address the issue #1 so recommend we go with this approach for now. -- 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
