[virt-tools-list] [libosinfo] Checksums for driver files
cfergeau at redhat.com
Wed Dec 12 15:43:20 UTC 2012
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 at redhat.com> wrote:
> > 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.
> 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.
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the virt-tools-list