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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.07.12 at 15:59, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2012-06-20 at 11:32 +0100, Jan Beulich wrote:
>> >>> On 20.06.12 at 11:45, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> > On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> >>> The most controversial decision was whether the embargo date might be
>> >>> extended after it had originally been set.  We resisted these
>> >>> suggestions, referring to the process document, which does not
>> >>> contemplate extending the disclosure period.  However, when a
>> >>> predisclosure list member pressured the discoverer into requesting an
>> >>> extension, we felt the best interpretation of the process document
>> >>> required us to acquiesce.
>> >>>
>> >>> Specifically, of course, we as a team would like clearer guidance from
>> >>> the process about whether, and if so under what circumstances, a
>> >>> predisclosure period should be extended.
>> >>
>> >> I think this should be done via (perhaps silent) consensus on the
>> >> pre-discosure list. Leaving the embargo time line determination
>> >> entirely to the discoverer isn't really suitable. He might provide an
>> >> initial suggestion, but we ought to set a period of time (say, a
>> >> week or less) during which adjustment proposals can be made.
>> > 
>> > The problem with this is that extending the embargo helps providers
>> > who are on the predisclosure list (a minority), but hurts those not on
>> > the list (the vast majority).  So there's a moral hazard with what you
>> > suggest: it is just way too easy for the people on the list to vote to
>> > make their own lives easier, not considering the plight of those who
>> > are not big enough or connected enough to be on the list.  Doing so
>> > also favors large players and incumbents against small players; doing
>> > so may well be considered anti-competitive and illegal in many
>> > jurisdictions.
>> > 
>> > The only way this would work is if the predisclosure list consisted
>> > exclusively of software providers, and specifically excluded service
>> > providers.  It should be possible to include all software providers on
>> > the list, since it's a relatively small number of entities.
>> > Furthermore, since software providers presumably care about the
>> > security of their customers, it would provide the incentive to make
>> > the embargo as short as is reasonable.
>> 
>> You need to take this in context with my proposal to have only
>> software vendors have a vote here, and to allow service
>> providers at most an observing (maybe recommending to a
>> limited degree) role.
> 
> (I'm going to reply elsewhere about my opinions on the existence of the
> pre-disclosure list at all, but for the purposes of responding here I'll
> assume we are going to keep it)
> 
> I think allowing the pre-disclosure list to have any "authority" in any
> case would be a mistake. There are certainly scenarios where even a
> vendor might want to delay the release for their own purposes. Perhaps
> their QA team is too slow, or they want to delay the security update
> until they have a new version of their s/w offering ready.
> 
> IMHO the predisclosure list should be purely about information flowing
> out of Xen.org to the list participants and requests for clarification
> going the other way. Membership of the predisclosure list should not
> infer any other special privilege or control over the security embargo
> process and we need to be explicit about that. Members of the list
> *already* have the privilege of being on the list, they should not
> expect to also have the privilege of having control over the timelines
> etc of individual security vulnerabilities. Influence over the process
> should happen during the formulation of the policy -- IOW in public
> where everyone, not some select group of downstreams who happen to be on
> the list, can have a say.

But in that case, negotiation of an embargo period becomes a
dead thing altogether - the discoverer saying something, it
would need to be followed, and in the absence of him stating
anything defaults would need to be applied. No other option
would exist, as no-one is given authority. Giving the security
team members authority in this respect would already make them
susceptible to pressure put onto them by other list members.

Jan

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