Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
<ijackson@xxxxxxxxxxxxxxxxxxxxxx> 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-discuss@xxxxxxxxxxxxxxxxxxxx
>   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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel