[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |