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

[Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>]

Xen Project Security Team writes ("Security policy ambiguities - XSA-108 
process post-mortem"):
> We welcome any feedback on our decisions and we look forward to
> clearer directions from the community.

Here is my own, purely personal, response with answers to the
questions asked.  NB that this is not the opinion of Citrix nor of
the Xen Project Security Team.  But I thought I would at least write
down something concrete for people to argue about.


> Sharing amongst predisclosure list members

I think that the answer should be `yes', in principle.  There seems
little point forbidding this.

Allowing greater sharing would perhaps allow problems with patches to
be discovered (and the revised patches developed) more easily.  We
should provide a clear channel for collaboration between predisclosure
list members.

Therefore, the policy should be extended by adding, before
`Organisations who meet the criteria', the new section:

  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
  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.

(That list obviously doesn't exist yet, but if the policy is approved
we will create it.)

One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider.  Both kinds of service provider
should be able to test the fix during the embargo.


> Deployment on public systems of fixed versions during embargo

These different understandings have led to some bad feelings - some
people feel that others have breached the embargo, while they felt
prevented from acting similarly.  This is very regrettable and I
apologise for my contribution to the unclarity in the policy.

I want to say clearly that I think everyone has acted in good faith.

My view is that the policy should be clarified to permit deployment
during embargo.  I see no practical reason for preventing it.  I would
add, following that list of bullet points:

  List members who are service providers may deploy fixed versions
  during the embargo, PROVIDED THAT any action taken by the service
  provider gives no indication (to their users or anyone else) as to
  the nature of the vulnerability.

This question is IMO partly linked to the previous one.


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.


> 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).


> Predisclosure list memembership

The policy should be amended to require applicants to provide the
information required, in the form of public URLs.  The team should not
be required to judge email aliases or enquire about their recipients
except to ensure that they don't look like personal aliases.

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
  security@xenproject if they wish to receive pre-disclosure of
  advisories.  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.

  The Security Team has no discretion to accept applications which do
  not provide all of the information required above.

  Please provide URLs which are accessible and legible on mobile phone
  browsers, which do not require cookies enabled to load, and which
  are useable with text mode browsers, browsers which do not execute
  Javascript, and with screen readers and other accessibility
  software.  If the member of the Xen Project Security Team who
  processes your application finds that their usual web browser does
  not display the required information, when presented with the URLs
  in your email, your application might be delayed or even rejected.


Ian.


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