From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Security vulnerability process, and CVE-2012-0217 Date: Mon, 2 Jul 2012 16:04:32 +0100 Message-ID: <1341241472.4625.115.camel@zakaz.uk.xensource.com> References: <20448.49637.38489.246434@mariner.uk.xensource.com> <4FE1AAB6020000780008AC16@nat28.tlf.novell.com> <4FE1C2E3020000780008AC77@nat28.tlf.novell.com> <1341237571.4625.94.camel@zakaz.uk.xensource.com> <4FF1D336020000780008D1FA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FF1D336020000780008D1FA@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, 2012-07-02 at 15:58 +0100, Jan Beulich wrote: > >>> On 02.07.12 at 15:59, Ian Campbell wrote: > > On Wed, 2012-06-20 at 11:32 +0100, Jan Beulich wrote: > >> >>> On 20.06.12 at 11:45, George Dunlap wrote: > >> > On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich wrote: > >> >>>>> On 19.06.12 at 20:16, Ian Jackson 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. Hrmm yes. We should certainly make it explicit that in the absence of an opinion from the discloser the security team can set the time line it thinks is appropriate, suing the default as a guideline only and endevouring to keep it as short as possible. Matt previously posted a link to https://www.ocert.org/disclosure_policy.html which contains """ The following time frames regulate oCERT embargo proposals: - 7 days, in case the issue is already well narrowed down and tested, requiring trivial configuration and/or code change - 14 days, standard embargo for most cases - 30 days, in case of critical and complex vulnerabilities (example, trivial exploitation of administrative privileges on a static library affecting a large number of packages), and with the agreement of all parties - under extremely exceptional circumstances, if the oCERT Team and all the parties involved feel the need for longer time, a 2 months embargo can be applied, in this case we would clearly document the decision for public review - in any circumstance reporter preference will always be honoured in case a joint agreement is not reached, as oCERT would be anyway unable to force its embargo """ which seems like a reasonable set of rules to me, modulo discussion about the specific time lines. > Giving the security > team members authority in this respect would already make them > susceptible to pressure put onto them by other list members. I think we can a) make it clear that list members don't have that authority and b) rely on the security team to resist such pressure better than disclosers and/or other list members. Ian.