On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > Having gone through the thread, I've prepared a three-part new > proposal email. > > I. Deployment with Security Team Permission > II. Predisclosure list memembership > III. Information sharing > IV. Fixes which seem to have rough consensus as they were > > Perhaps I should be checking the current web page out as a git tree > and preparing a patch series ? > > Thanks, > Ian. > > > I. Deployment with Security Team Permission > =========================================== > > Permitting deployment during embargo seemed to have rough consensus on > the principle. We seemed to be converging on the idea that the > Security Team should explicitly set deployment restrictions for each > set of patches. So I suggest something like this: > > List members may deploy fixed versions during the embargo, only with > permission from the Security Team. The Security Team will normally > permit such deployment, even for systems where VMs are managed or > used by non-members of the predisclosure risk. Permission for > deployment, and any restrictions, will be stated in the embargoed > advisory text. > > The Security Team will impose deployment restrictions only insofar > as it is necessary to prevent the exposure of technicalities (for > example, differences in behaviour) which present a significant risk > of rediscovery of the vulnerability. Such situations are expected > to be rare.
+1 > II. Predisclosure list memembership > =================================== > > The idea of objective criteria seemed to find favour, and the general > scheme I proposed. > > Lars suggested we should "test" this. I think therefore that we > should invite a participants in this thread to write up and post > applications which we can then test against the proposed policy. But > we should probably wait until we have rough consensus on the new > policy shape. > > I have dropped the section about bad websites. I don't think its lack > will make much difference to the way applications are processed in > practice, and I still think documenting the issue would be useful, but > it's clear that I'm not going to get consensus for it. > > Changes that I have made are: > - Applications to be made, and decisions sent, to a public mailing list > - Explicitly say that the Security Team decide and that they have no > discretion > - Explicitly say that there is appeal to the project governance process > (Lars: perhaps this should say something different or more specific?) > > > So as I said before, applicants should be required to: > > - Provide information on their public web pages which makes > it clear that and why they are eligible; > > - Specifically, publicly state that and how they are using Xen > (so that the Security Team can verify eligibility); > > - Provide a way for members of the public to responsibly report > security problems to the applicant, just as the Xen Project does. > > The Security Team should be forbidden from trying to hunt down > eligibility information etc. and should instead be mandated to reject > incomplete requests. > > Specifically, I propose that the section on list membership > applications be entirely replaced with this: > > Organisations who meet the criteria should contact > predisclosure-applications@xenproject if they wish to receive > pre-disclosure of advisories. That is a public mailing list. > > You must include in the e-mail: > > * The name of your organization. > > * Domain name(s) which you use to provide Xen software/services. > > * A brief description of why you fit the criteria. > > * If not all of your products/services use Xen, a list of (some > of) your products/services (or categories thereof) which do. > > * Link(s) to current public web pages, belonging to your > organisation, for each of following pieces of information: > > o Evidence of your status as a service/software provider: > + If you are a public hosting provider, your public rates > or how to get a quote > + If you are a software provider, how your > software can be downloaded or purchased > + If you are an open-source project, a mailing list > archive and/or version control repository, with > active development > > o Evidence of your status as a user of Xen: > + Statements about, or descriptions of, your eligible > production services or released software, from which it is > immediately evident that they use Xen. > > o Information about your handling of security problems: > + Your invitation to members of the public, who discover > security problems with your products/services, to report > them in confidence to you; > + Specifically, the contact information (email addresses or > other contact instructions) which such a member of the > public should use. > > Blog postings, conference presentations, social media pages, > Flash presentations, videos, sites which require registration, > anything password-protected, etc., are not acceptable. PDFs of > reasonable size are acceptable so long as the URL you provide is > of a ordinary HTML page providing a link to the PDF. > > If the pages are long and/or PDFs are involved, your email > should say which part of the pages and documents are relevant. > > * A statement to the effect that you have read this policy and > agree to abide by the terms for inclusion in the list, > specifically the requirements regarding confidentiality during > an embargo period. > > * The single (non-personal) email alias you wish added to the > predisclosure list. > > Your application will be determined by the Xen Project Security > Team, and their decision posted to the list. The Security Team has > no discretion to accept applications which do not provide all of the > information required above. > > If you are dissatisfied with the Security Team's decision you may > appeal it via the Xen Project's governance processes. +1 > III. Information-sharing > ======================== > > Permitting sharing of embargoed fixes amongst predisclosure list > seemed to have rough consensus in principle. There was some > discussion about the details. I remain convinced that my previous > proposal is correct and I think we should be able to get consensus for > it. > > So I reproduce it (unchanged from my previous proposed wording): > > List members are allowed to share fixes to embargoed issues, > analysis, etc., with the security teams of other list members. > Technical measures must be taken to prevents non-list-member "to prevents" => either "which prevents" or "to prevent" I take it in general the technical measures you envision is pgp / gpg? > organisations, or unauthorised staff in list-member organisations, > from obtaining the embargoed materials. > > The Xen Project provides the mailing list > xen-security-issues-disc...@lists.xenproject.org > for this purpose. List members are encouraged to use it but > may share with other list members' security teams via other > channels. > > The -discuss list's distribution is identical to that of the primary > predisclosure list xen-security-issues. Recipient organisations who > do not wish to receive all of the traffic on -discuss should use > recipient-side email filtering based on the provided `List-Id'. > > The -discuss list is moderated by the Xen Project Security Team. > Announcements of private availability of fixed versions, and > technical messages about embargoed advisories, will be approved. > Messages dealing with policy matters will be rejected with a > reference to the Security Team contact address and/or public Xen > mailing lists. > > > IV. Fixes which seem to have rough consensus as they were > ========================================================= > > (Reproduced unchanged from my previous proposed wording:) > > The Security Team should not be invited to give permission > specifically for the release of patched software. I think the rider > was mistakenly merged into the final the bullet point in the list. It > should be separated out. Also, the predisclosure list members should > not be invited to consult the discoverer. > > The note about CVE numbers should be moved into the list of > forbidden-disclosures, as a new bullet point. So overall I would > delete that whole paragraph about CVEs (we don't need the historical > information) and adjust the end of the forbidden disclosures to read: > > ... > * patched software (even in binary form) > * CVE number(s) > > without prior consultation with security@xenproject. +1 > > >> Service announcements to non-list-member users during embargo > > We should add just below the list of bullet points of things which may > be disclosed: > > Where the list member is a service provider who intends to take > disruptive action such as rebooting as part of deploying a fix (see > above): the list member's communications to its users about the > service disruption may mention that the disruption is to correct a > security issue, and relate it to the public information about the > issue (as listed above). +1 -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
