While the Xen sources have recently become digitally signed by xen.org (which is just great), there is still a problem that its various Makefiles download (and subsequently build) various 3rd party software via wget (e.g. ioemmu, grub, tboot, etc). Unless I''m missing something, the downloaded 3rd part software is never verified in any way. From the security point of view, it is equal to say that Xen downloads random code from the web, and unconditionally executes it. So, this not only allows for building potentially compromised Xen packages, but also is a threat to the developers machine, where the (untrusted) Makefiles of the unverified 3rd party software are run. Consequently, I have the following suggestions: 1) Push on the vendors of the 3rd party components you use in the build to sign their software, verify the signatures after download in your Makefile, 2) Until the 3rd party vendors implement signing of their software, add hardcoded list of hashes for the specific versions of the software version you use in the build (e.g. md5sum and then use md5sum --check in the Makefile for verification that what you downloaded is good). joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/07/2010 16:12, "Joanna Rutkowska" <joanna@invisiblethingslab.com> wrote:> While the Xen sources have recently become digitally signed by xen.org > (which is just great), there is still a problem that its various > Makefiles download (and subsequently build) various 3rd party software > via wget (e.g. ioemmu, grub, tboot, etc). Unless I''m missing something, > the downloaded 3rd part software is never verified in any way.We download tarballs from http://xenbits.xensource.com/xen-extfiles rather than random 3rd party sites. And qemu from our very own git repository also on xenbits. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/06/10 17:21, Keir Fraser wrote:> On 06/07/2010 16:12, "Joanna Rutkowska" <joanna@invisiblethingslab.com> > wrote: > >> While the Xen sources have recently become digitally signed by xen.org >> (which is just great), there is still a problem that its various >> Makefiles download (and subsequently build) various 3rd party software >> via wget (e.g. ioemmu, grub, tboot, etc). Unless I''m missing something, >> the downloaded 3rd part software is never verified in any way. > > We download tarballs from http://xenbits.xensource.com/xen-extfiles rather > than random 3rd party sites. And qemu from our very own git repository also > on xenbits. >But you use plaintext connection, which, in security, means random code. I think we have already went through this last time when discussing the signing process for Xen ;) joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/07/2010 16:23, "Joanna Rutkowska" <joanna@invisiblethingslab.com> wrote:>> We download tarballs from http://xenbits.xensource.com/xen-extfiles rather >> than random 3rd party sites. And qemu from our very own git repository also >> on xenbits. >> > But you use plaintext connection, which, in security, means random code. > I think we have already went through this last time when discussing the > signing process for Xen ;)Okay, then make a patch, including hashes for our current collection of downloads. K. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/06/10 17:24, Keir Fraser wrote:> On 06/07/2010 16:23, "Joanna Rutkowska" <joanna@invisiblethingslab.com> > wrote: > >>> We download tarballs from http://xenbits.xensource.com/xen-extfiles rather >>> than random 3rd party sites. And qemu from our very own git repository also >>> on xenbits. >>> >> But you use plaintext connection, which, in security, means random code. >> I think we have already went through this last time when discussing the >> signing process for Xen ;) > > Okay, then make a patch, including hashes for our current collection of > downloads.I''m not a Xen developer. I do not sign your tarballs... joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/07/2010 16:27, "Joanna Rutkowska" <joanna@invisiblethingslab.com> wrote:>>> But you use plaintext connection, which, in security, means random code. >>> I think we have already went through this last time when discussing the >>> signing process for Xen ;) >> >> Okay, then make a patch, including hashes for our current collection of >> downloads. > > I''m not a Xen developer. I do not sign your tarballs...Perhaps best then to sign the tarballs we have on xenbits, and verify the signatures when we download tarballs. Ian Jackson might pick that up as a work item. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 07/06/10 17:34, Keir Fraser wrote:> On 06/07/2010 16:27, "Joanna Rutkowska" <joanna@invisiblethingslab.com> > wrote: > >>>> But you use plaintext connection, which, in security, means random code. >>>> I think we have already went through this last time when discussing the >>>> signing process for Xen ;) >>> >>> Okay, then make a patch, including hashes for our current collection of >>> downloads. >> >> I''m not a Xen developer. I do not sign your tarballs... > > Perhaps best then to sign the tarballs we have on xenbits, and verify the > signatures when we download tarballs. Ian Jackson might pick that up as a > work item. >For me (=user) that would be just fine, but I think *for you* (=vendor) it might be better to just generate a list of hashes via md5sum and include this file (say ''sources'') in your tarball, and get your Makefiles just do md5sum -c sources after it downloads them. The difference is subtle, but I think you show this way that these are external components, originally not signed, not created by you (but only somehow verified, hence the hash). If you sign something with your key, it suggests you have somehow generated it yourself. I know it''s subtle. joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2010-Jul-06 15:50 UTC
Re: [Xen-devel] Xen signing and wget [and 3 more messages]
Joanna Rutkowska writes ("[Xen-devel] Xen signing and
wget"):> While the Xen sources have recently become digitally signed by xen.org
> (which is just great), there is still a problem that its various
> Makefiles download (and subsequently build) various 3rd party software
> via wget (e.g. ioemmu, grub, tboot, etc). Unless I''m missing
something,
> the downloaded 3rd part software is never verified in any way.
You are right, and you''re right that this could be improved.
I think the correct solution is to have the xen.hg tree contain the
expected sha hashes of the downloaded items. These files change very
rarely, we don''t really want to be signing them out of context with
our codesigning keys, we want to make sure you get the corresponding
version, and downloading and checking a signature as well as the
tarball would complicate the build (it would start to require gnupg).
So if you would like to prepare a patch to that effect I''d be very
pleased :-).
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Joanna Rutkowska
2010-Jul-06 15:56 UTC
Re: [Xen-devel] Xen signing and wget [and 3 more messages]
On 07/06/10 17:50, Ian Jackson wrote:> Joanna Rutkowska writes ("[Xen-devel] Xen signing and wget"): >> While the Xen sources have recently become digitally signed by xen.org >> (which is just great), there is still a problem that its various >> Makefiles download (and subsequently build) various 3rd party software >> via wget (e.g. ioemmu, grub, tboot, etc). Unless I''m missing something, >> the downloaded 3rd part software is never verified in any way. > > You are right, and you''re right that this could be improved. > > I think the correct solution is to have the xen.hg tree contain the > expected sha hashes of the downloaded items. These files change very > rarely, we don''t really want to be signing them out of context with > our codesigning keys, we want to make sure you get the corresponding > version, and downloading and checking a signature as well as the > tarball would complicate the build (it would start to require gnupg). > > So if you would like to prepare a patch to that effect I''d be very > pleased :-). >Sorry, but I''m swamped enough with Qubes-specific things, and just cannot justify resources for this task at the moment (I don''t really understand the whole Xen build process well, and would have to spend extra time investigating it). joanna. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel