[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217


  • To: Thomas Goirand <thomas@xxxxxxxxxx>
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 27 Jun 2012 20:14:03 +0100
  • Cc: xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Wed, 27 Jun 2012 19:10:40 +0000
  • Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

> I find the concept of "Xen Cloud provider size threshold"
> quite anti competitive. Why would a bigger provider, would
> be offered a substantial advantage over the smaller one?

This came up with end providers for Linux disclosure years back and in the
end we said no for all sorts of reasons. The main one being that it is
nigh on impossible to set a "fair" policy. The fact you'd have to keep
adding/removing people as their size changes or importance changes, and
also the fact that the more people you tell the more leaks you get (note
not 'it might leak', that's a given, the question is how much).

It was also readily apparent that you'd have to have a policy that was
written, approved by lawyers and clear and strong enough to stand a
potential judicial review by an aggreived major vendor, or someone wanting
a cheap PR point against their rivals.

It also creates problem incentives. Cloud provider A who is not in the
cartel will not report bugs that only their rivals who are cartel members
get to see first. They'll instead report it to their friends, fix in
private and then go public. So you fracture the reporting environment, and
you get lots of zero day "fixes" from providers that may well be
inadequate or just badly designed.

There are people who get early disclosures on the kernel, but they don't
get them because the community policy covers them but because they have
three letter initials and undoubtedly intercept and monitor the relevant
security lists 8). They wouldn't be doing their job if they didn't.

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
> > One particular issue here which also relates to the predisclosure
> > membership criteria, is whether large indirect consumers of Xen should
> > be on the predisclosure list in their own right.  That would allow
> > them to deploy the fix before the embargo date.  It would also allow
> > them to prepare for testing and deployment, before the fix is
> > available from their vendor (who would in this scenario also be
> > entitled to be a predisclosure list member).
> >   
> 
> And other hosting providers not in the list? They can be hacked and die,
> while the big ones are safe?
> 
> Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
> If you reject me from such list, why? What's the procedure to be on such
> list?

Your lawyers sue them, or you set up a rival "fair reporting" list and
exclude members of the other predisclosure group, do your own private
fixing and then zero day hand them over to Xen.

Providing your group is well publicised most people will tell both
anyway and given the PR battle will probably favour the 'small oppressed'
division you'll probably get more of the "one group only" bugs. Quite
frankly I'd also expect the small guys to find most of the holes.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.