Security policy ambiguities - XSA-108 process post-mortem

Security policy ambiguities - XSA-108 process post-mortem

[Xen Project Security Team]

create !
thanks

XSA-108 had a lot of media coverage and generated a lot of interest of
various kinds.  This ended up stress-testing some of our policy and
processes.  During the embargo period the Xen Project Security Team
were faced with some difficult questions of policy interpretation.

Additionally, during the embargo period we had to hastily formalise
our internal tracking arrangements for predisclosure list membership
applications.  We intend to further streamline that system.


A summary of the policy questions, and the answers we gave, is below.
We hope that the community will work towards improving the policy.  As
the Security Team, our role is to implement the policy, not to set it,
so in this message we don't take a position on how the policy should
be clarified.

The Security Team expects that members of the Xen Project community
will respond to this thread (or other threads on this subject) with
everything from discussion of matters of principle to specific wording
proposals.

We welcome any feedback on our decisions and we look forward to
clearer directions from the community.

Thanks,
Xen Project Security Team.


Sharing amongst predisclosure list members
==========================================

The policy says:

  Specifically, prior to the embargo date, pre-disclosure list members
  should not make available, even to their own customers and partners:
   ...
    * patched software (even in binary form) without prior
      consultation with security@xenproject and/or the discoverer.

It is (still!) ambiguous whether predisclosure list members may share
fixes and other information with other predisclosure list members.  We
intended to fix this ambiguity following the XSA-7 discussion but
the policy was never updated.

During the XSA-108 embargo the Security Team were asked whether this
permitted; we concluded that since we had said `yes' last time, and
documented this in the XSA-7 postmortem, and the community had failed
to change the policy, we should probably say `yes' again.

The community should formally correct this ambiguity.


Deployment on public systems of fixed versions during embargo
=============================================================

It is ambiguous whether the wording above prohibits deployment by a
service provider of patched hosting software running customer VMs.
Some predisclosure list members thought that this was prohibited;
others thought that it was permitted and accordingly deployed the
XSA-108 fix during the embargo.

This question should be resolved, clearly, one way or the other.


Service announcements to non-list-member users during embargo
=============================================================

The policy says:

  List members are allowed to make available to their users only the
  following:

    * The existance of an issue
    * The assigned XSA number
    * The planned disclosure date

During the XSA-108 embargo, some service providers wished to make
announcements to their users, for example to notify their users that
their VMs will be rebooted.  The Security Team received enquiries
asking whether that was permitted; observing that some other providers
had read the policy as permitting this and already made such
announcements, we replied saying that we did not object.

The situation should be clarified.


Predisclosure list memembership
===============================

The Xen Project's policy wording on predisclosure list membership was
ambiguous and difficult for the team to work with.  In general when
the rules were ambiguous we tended towards approving applications
which appeared to be from genuine entities, seemed to be applying in
good faith, and who seemed to meet what we saw as the general
principles behind the rules.


Questions which arose include:

Applicants who do not have a public security policy.  The Xen Project
security policy asks for `A link to a web page with your security
policy statement' but doesn't explain what a `security policy
statement' is.  We received a number of applications accompanied by
links to a wide variety of kinds of web pages, including privacy
policies and other documents which do not easily fit into what one
would think of as a `security policy statement'.  Under the
circumstances we ended up mostly waiving this requirement because it
was difficult to pin down the meaning.

Applicants who do not provide a public security reporting address.
This makes it difficult for the Xen Project Security Team to verify
that the people emailing us are properly authorised.  It also invites
entities to benefit from the Xen Project's mature security response
process even when they themselves are so irresponsible as to provide
no way for members of the public to responsibly report security
problems.

Applicants where it is not clear whether they actually use Xen; or, if
Xen is mentioned, where it is unclear how they use it.  The Security
Team spent some time hunting through some applicants' websites and/or
doing websearches to verify whether each applicant actually qualified.
This is not a workable process (especially in crises).

Applicants where the delivery scope of the provided email alias is or
appears to be wider than the policy contemplates.  The Security Team
sometimes made enquiries with applicants about the distribution of
these aliases.  The responses received are of course not verifiable
by the Team.

Verifying the status and eligiblity of applicants was therefore a
difficult and tedious process.  Partly because applicants didn't
always supply the information in the most convenient format; partly
because the information wasn't always on applicants' websites; and
partly simply because some applicants websites were frustratingly
difficult to navigate.


There were three categories of applicant where we felt the policy
required us to reject the application:

Applicants who mentioned proof of concept, experimental or research
Xen setups in support of their application, and did not appear to have
(or be distributing) any Xen deployed in production.

Providers of ancillary software (eg, installers, control panels) who
did not themselves provide modified versions of Xen, but rely on
distro or vendor Xen packages.

Consultants or contractors who may help users configure and manage
systems - although we did tell these that their users might qualify in
their own right.


We hope that the community will set a clearer policy which allows for
straightforward decisionmaking on predisclosure list applications.


-- 

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

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

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

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> 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@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.
> 
> (That list obviously doesn't exist yet, but if the policy is approved
> we will create it.)

Ian, this is a very good suggestion. 

> 
> 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 agree. If we didn’t allow deployment during an embargo a lot more users would be at risk.

However, in this context we do need to look at a number of questions:
a) Risk of someone reverse engineering the vulnerability during deployment. 
b) GPL (or license) compliance - this may be a non-issue, but I would like to get some advice on it. 

In the case of XSA 108 both were not an issue, because the hypervisor is not accessible by a user of a cloud provider.
However, if the vulnerability had been in another component this may be different.


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

I think this does text does not address a) and b)

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

This is a good list.
I do think we should test this though to make sure it actually works. I think there are a few areas which may be ambiguous or not clear enough.

I also think we do need to address websites in non-english languages would be handled. Of course we do not want to discriminate. 

> 
>  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@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> > My view is that the policy should be clarified to permit deployment
> > during embargo.  I see no practical reason for preventing it.  
> 
> I agree. If we didn’t allow deployment during an embargo a lot more
> users would be at risk.
> 
> However, in this context we do need to look at a number of questions:
> 
> a) Risk of someone reverse engineering the vulnerability during
> deployment.

This is what my caveat is intended to address.

> b) GPL (or license) compliance - this may be a non-issue, but I
> would like to get some advice on it.

Feel free to get advice but I can assure you that this is a
non-issue.

> In the case of XSA 108 both were not an issue, because the hypervisor is not accessible by a user of a cloud provider.
> However, if the vulnerability had been in another component this may be different.

If the vulnerability were in a component that were distributed to the
users then 1. the GPL would be engaged 2. my caveat would be violated.

> >  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.
> 
> I think this does text does not address a) and b)

It may be that this wording should be improved since obviously it
isn't clear enough.

> >  The Security Team has no discretion to accept applications which do
> >  not provide all of the information required above.
> 
> This is a good list.
> 
> I do think we should test this though to make sure it actually works. I think there are a few areas which may be ambiguous or not clear enough.

It might be worth looking at constructing some some hypothetical or
historical applications and judging them against these criteria.

> I also think we do need to address websites in non-english languages
> would be handled. Of course we do not want to discriminate.

So far, what the security team have done is use online machine
translation services.  That seems to have been sufficient so far.

Ian.

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

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Thu, Oct 9, 2014 at 10:37 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
>> > My view is that the policy should be clarified to permit deployment
>> > during embargo.  I see no practical reason for preventing it.
>>
>> I agree. If we didn’t allow deployment during an embargo a lot more
>> users would be at risk.
>>
>> However, in this context we do need to look at a number of questions:
>>
>> a) Risk of someone reverse engineering the vulnerability during
>> deployment.
>
> This is what my caveat is intended to address.

That's not how I understood your caveat (assuming you mean
"...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.")

Just to be clear what I'm talking about (and what I think Lars is
talking about): Say that there was a fix that was expected to have
noticeable effects on existing functionality -- for example, breaking
certain (obscure but occasionally used) configurations, or having a
measurable performance impact on certain not-uncommon workloads.  This
might clue the attacker in to what code to audit to try to find the
vulnerability.

For one, your caveat is pretty ambiguous: many people took Amazon's
rebooting to mean that it was a really serious vulnerability (i.e.,
privilege escalation).  In this case that turned out to be wrong, but
what it if *had* been for a bug like XSA-7?  Would that constitute
"giving indication as to the nature of the vulnerability"?

For two, I would have interpreted this about other actions surrounding
the deployment, not actually the deployment itself.

I think that the security team should attempt to determine whether
pre-disclosure deployment might give away too much information, and
specifically say in each advisory whether early deployment is allowed
or not, potentially with specifications about what kind of deployments
will be allowed (if necessary).  Most of the time this will just be,
"Rebooting servers to deploy this fix is allowed", but it leaves the
option open to change it if necessary.

 -George

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

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Campbell]

On Thu, 2014-10-09 at 12:24 +0100, George Dunlap wrote:
> On Thu, Oct 9, 2014 at 10:37 AM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> >> On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> >> > My view is that the policy should be clarified to permit deployment
> >> > during embargo.  I see no practical reason for preventing it.
> >>
> >> I agree. If we didn’t allow deployment during an embargo a lot more
> >> users would be at risk.
> >>
> >> However, in this context we do need to look at a number of questions:
> >>
> >> a) Risk of someone reverse engineering the vulnerability during
> >> deployment.
> >
> > This is what my caveat is intended to address.
> 
> That's not how I understood your caveat (assuming you mean
> "...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.")
> 
> Just to be clear what I'm talking about (and what I think Lars is
> talking about): Say that there was a fix that was expected to have
> noticeable effects on existing functionality -- for example, breaking
> certain (obscure but occasionally used) configurations, or having a
> measurable performance impact on certain not-uncommon workloads.  This
> might clue the attacker in to what code to audit to try to find the
> vulnerability.

I was wondering about this sort of thing too.

We don't want to leave this up to individual list members, otherwise we
are back in the situation where two members reach different conclusions
and one of them ends up feeling aggrieved. Plus I don't think we can
expect all list members to have the technical understanding to make that
call in the first place.

Ian.
> 
> For one, your caveat is pretty ambiguous: many people took Amazon's
> rebooting to mean that it was a really serious vulnerability (i.e.,
> privilege escalation).  In this case that turned out to be wrong, but
> what it if *had* been for a bug like XSA-7?  Would that constitute
> "giving indication as to the nature of the vulnerability"?
> 
> For two, I would have interpreted this about other actions surrounding
> the deployment, not actually the deployment itself.
> 
> I think that the security team should attempt to determine whether
> pre-disclosure deployment might give away too much information, and
> specifically say in each advisory whether early deployment is allowed
> or not, potentially with specifications about what kind of deployments
> will be allowed (if necessary).  Most of the time this will just be,
> "Rebooting servers to deploy this fix is allowed", but it leaves the
> option open to change it if necessary.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

Re: Security policy ambiguities - XSA-108 process post-mortem

[Jan Beulich]

>>> On 09.10.14 at 13:24, <George.Dunlap@eu.citrix.com> wrote:
> I think that the security team should attempt to determine whether
> pre-disclosure deployment might give away too much information, and
> specifically say in each advisory whether early deployment is allowed
> or not, potentially with specifications about what kind of deployments
> will be allowed (if necessary).  Most of the time this will just be,
> "Rebooting servers to deploy this fix is allowed", but it leaves the
> option open to change it if necessary.

We're sometimes already struggling determining the set of
consequences a certain issue may have (see statements like
"... cannot be excluded"). I think anticipating what sufficiently
"qualified" people may be able to guess from early deployment
would end up being rather difficult.

Jan

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On 10/10/2014 03:25 PM, Jan Beulich wrote:
>>>> On 09.10.14 at 13:24, <George.Dunlap@eu.citrix.com> wrote:
>> I think that the security team should attempt to determine whether
>> pre-disclosure deployment might give away too much information, and
>> specifically say in each advisory whether early deployment is allowed
>> or not, potentially with specifications about what kind of deployments
>> will be allowed (if necessary).  Most of the time this will just be,
>> "Rebooting servers to deploy this fix is allowed", but it leaves the
>> option open to change it if necessary.
> We're sometimes already struggling determining the set of
> consequences a certain issue may have (see statements like
> "... cannot be excluded"). I think anticipating what sufficiently
> "qualified" people may be able to guess from early deployment
> would end up being rather difficult.

Perhaps -- but it seems to me to be the least risky of all the alternatives.

As far as I can tell we basically have the following options:

1. Never allow people to deploy during the embargo period.

This eliminates the possibility that someone will be helped to gain 
information about the vulnerability by comparing a patched system to an 
unpatched one.  However, it means that cloud operators may spend a short 
amount of time "publicly vulnerable" while they reboot their systems.  I 
assume it would significantly increase the difficulty of coordinating 
such a deployment, as you would have to reboot *all* your servers in the 
smallest time window possible, instead of being able to stage it over 
several days.

It also increases the temptation for operators to "cheat" by starting 
the process a little bit early.  This I think could lead to more 
significant problems community-wise: with incentive to break the rules, 
enforcement becomes an issue -- and I'm sure none of the team want to 
have to deal with that.

2. Always allow people to deploy during the embargo period.

This is simple on the security team, and minimizes the "publicly 
vulnerable time".  It makes deployments easier to coordinate, and avoids 
adding an incentive for "bending" the rules.

However, it does in theory allow an attacker the ability to gain 
information about the vulnerability by comparing patched systems to 
unpatched systems.  In practice, the vast majority of the time the 
measurable difference in functionality will be like finding a needle in 
a haystack; and if the attacker had ever even thought to try the 
functionality (e.g., XSA-7), she would have already known about the 
bug.  But that may not always be the case.

3. Have the security team attempt to evaluate the risk.

This adds work to the security team.  But it at least allows the 
possibility that, in cases where it's pretty clear that early deployment 
*would* give clear hints to an attacker, they could decide to include 
deployment in the embargo.

4. Have individual cloud operators evaluate the risk.

This seems like a recipe for disaster.

I think #1 is too risky, particularly from a community perspective. But 
maybe I'm being a bit pessimistic.

In my mind, #3 is basically exactly the same as #2, except that in cases 
where there would clearly be a problem, the team has an option of 
embargoing deployment as well.

I just spent about 10 minutes skimming through the 80 or so XSAs on 
http://xenbits.xen.org/xsa/.  In most of the cases, it was pretty clear 
that the only behavior that changed would be behavior which would 
already have clued an attacker into the existence of a potential 
vulnerability.  For example, in XSA-108, beforehand some reads from the 
reserved x2apic range would have returned values whereas now they would 
#GP.  But if the attacker knew that they returned values, it already 
would have occurred to her to see if they returned anything of interest.

I didn't notice a single exception to this, though admittedly I didn't 
spend much time looking at it.

This suggests to me that #2 is probably not that dangerous the majority 
of the time.  It also suggests that there may be a simple criteria that 
can be applied for #3 that can eliminate most of the guesswork: Is 
anything in the original behavior being changed likely to lead an 
attacker to think that there may be a vulnerability there?  In the case 
of basically all of them, I think the answer there would be "yes".

So at the moment I would favor #3, then #2; I'm not in favor of #1 but I 
wouldn't strenuously argue against it.  But the main thing is that we  
have a clear policy.

  -George

Re: Security policy ambiguities - XSA-108 process post-mortem

[James Bulpin]

George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
>
> As far as I can tell we basically have the following options:
> 
> 1. Never allow people to deploy during the embargo period.
> 
> This eliminates the possibility that someone will be helped to gain
> information about the vulnerability by comparing a patched system to an
> unpatched one.  However, it means that cloud operators may spend a short
> amount of time "publicly vulnerable" while they reboot their systems.  I
> assume it would significantly increase the difficulty of coordinating
> such a deployment, as you would have to reboot *all* your servers in the
> smallest time window possible, instead of being able to stage it over
> several days.
> 
> It also increases the temptation for operators to "cheat" by starting
> the process a little bit early.  This I think could lead to more
> significant problems community-wise: with incentive to break the rules,
> enforcement becomes an issue -- and I'm sure none of the team want to
> have to deal with that.
> 
> 2. Always allow people to deploy during the embargo period.
> 
> This is simple on the security team, and minimizes the "publicly
> vulnerable time".  It makes deployments easier to coordinate, and avoids
> adding an incentive for "bending" the rules.
> 
> However, it does in theory allow an attacker the ability to gain
> information about the vulnerability by comparing patched systems to
> unpatched systems.  In practice, the vast majority of the time the
> measurable difference in functionality will be like finding a needle in
> a haystack; and if the attacker had ever even thought to try the
> functionality (e.g., XSA-7), she would have already known about the
> bug.  But that may not always be the case.
> 
> 3. Have the security team attempt to evaluate the risk.
> 
> This adds work to the security team.  But it at least allows the
> possibility that, in cases where it's pretty clear that early deployment
> *would* give clear hints to an attacker, they could decide to include
> deployment in the embargo.
> 
> 4. Have individual cloud operators evaluate the risk.
> 
> This seems like a recipe for disaster.
> 
> I think #1 is too risky, particularly from a community perspective. But
> maybe I'm being a bit pessimistic.
> 
> In my mind, #3 is basically exactly the same as #2, except that in cases
> where there would clearly be a problem, the team has an option of
> embargoing deployment as well.
> 
> I just spent about 10 minutes skimming through the 80 or so XSAs on
> http://xenbits.xen.org/xsa/.  In most of the cases, it was pretty clear
> that the only behavior that changed would be behavior which would
> already have clued an attacker into the existence of a potential
> vulnerability.  For example, in XSA-108, beforehand some reads from the
> reserved x2apic range would have returned values whereas now they would
> #GP.  But if the attacker knew that they returned values, it already
> would have occurred to her to see if they returned anything of interest.
> 
> I didn't notice a single exception to this, though admittedly I didn't
> spend much time looking at it.
> 
> This suggests to me that #2 is probably not that dangerous the majority
> of the time.  It also suggests that there may be a simple criteria that
> can be applied for #3 that can eliminate most of the guesswork: Is
> anything in the original behavior being changed likely to lead an
> attacker to think that there may be a vulnerability there?  In the case
> of basically all of them, I think the answer there would be "yes".
> 
> So at the moment I would favor #3, then #2; I'm not in favor of #1 but I
> wouldn't strenuously argue against it.  But the main thing is that we
> have a clear policy.

I like #3 but as clarified in this paragraph:

> In my mind, #3 is basically exactly the same as #2, except that in cases
> where there would clearly be a problem, the team has an option of
> embargoing deployment as well.

i.e. embargoing deployment is an exceptional case.

Cheers,
James

-- 
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.

Re: Security policy ambiguities - XSA-108 process post-mortem

[James McKenzie]

On 29/10/14 13:27, James Bulpin wrote:
> George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"):
>> [snip]
>>
>> As far as I can tell we basically have the following options:
>>
>> 1. Never allow people to deploy during the embargo period.
>>
>> 2. Always allow people to deploy during the embargo period.
>>
>> 3. Have the security team attempt to evaluate the risk.
>>
>> 4. Have individual cloud operators evaluate the risk.
>>
>> This seems like a recipe for disaster.


1 and 3 seem like a recipe for disaster as organizations and individual people
who have become aware of issues may have legal and other obligations to their
users, it would also add a fairly strong incentive for a large operator not
to share any issues that they, or a contractor, had found until they had
completed a mitigation.

Perhaps:

5) Have the security team discuss with the discoverer if fixes should be
permitted during the embargo period before the discovery is announced to
the list.

J.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Jan Beulich]

>>> On 19.01.15 at 21:36, <james.mckenzie@bromium.com> wrote:
> On 29/10/14 13:27, James Bulpin wrote:
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process 
> post-mortem"):
>>> [snip]
>>>
>>> As far as I can tell we basically have the following options:
>>>
>>> 1. Never allow people to deploy during the embargo period.
>>>
>>> 2. Always allow people to deploy during the embargo period.
>>>
>>> 3. Have the security team attempt to evaluate the risk.
>>>
>>> 4. Have individual cloud operators evaluate the risk.
>>>
>>> This seems like a recipe for disaster.
> 
> 
> 1 and 3 seem like a recipe for disaster as organizations and individual 
> people
> who have become aware of issues may have legal and other obligations to 
> their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
> 
> Perhaps:
> 
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.

Even if this looks like a good idea from an abstract pov, I'm not sure
it's practical: In particular in the case where the security team
determines that by deployment learning about details of the
vulnerability might be possible, but the discoverer insists on allowing
deployment, we'd end up with a rather undesirable situation.

Jan

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Mon, Jan 19, 2015 at 8:36 PM, James McKenzie
<james.mckenzie@bromium.com> wrote:
> On 29/10/14 13:27, James Bulpin wrote:
>>
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process
>> post-mortem"):
>>>
>>> [snip]
>>>
>>> As far as I can tell we basically have the following options:
>>>
>>> 1. Never allow people to deploy during the embargo period.
>>>
>>> 2. Always allow people to deploy during the embargo period.
>>>
>>> 3. Have the security team attempt to evaluate the risk.
>>>
>>> 4. Have individual cloud operators evaluate the risk.
>>>
>>> This seems like a recipe for disaster.
>
>
>
> 1 and 3 seem like a recipe for disaster as organizations and individual
> people
> who have become aware of issues may have legal and other obligations to
> their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
>
> Perhaps:
>
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.

Right -- I think that the general approach is almost always "defer to
the discoverer", specifically to encourage early reporting.  Perhaps
it's worth making more explicit somewhere.

 -George

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

Hi all,
I am assuming this question is in effect resolved. The proposed (and agreed) text basically states that security advisories state whether people will be allowed to deploy. The underlying assumption is that usually this is the case, unless there is a very good reason not to. How the security team handles these does not really need to be codified and could be based on whether the deployment would allow reverse engineering the issue (this would be very rare) and thus put everyone at risk, the discoverer stating that he/she not wanting a deployment, or any other reasons. 
Regards
Lars

> On 19 Jan 2015, at 20:36, James McKenzie <james.mckenzie@bromium.com> wrote:
> 
> On 29/10/14 13:27, James Bulpin wrote:
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"):
>>> [snip]
>>> 
>>> As far as I can tell we basically have the following options:
>>> 
>>> 1. Never allow people to deploy during the embargo period.
>>> 
>>> 2. Always allow people to deploy during the embargo period.
>>> 
>>> 3. Have the security team attempt to evaluate the risk.
>>> 
>>> 4. Have individual cloud operators evaluate the risk.
>>> 
>>> This seems like a recipe for disaster.
> 
> 
> 1 and 3 seem like a recipe for disaster as organizations and individual people
> who have become aware of issues may have legal and other obligations to their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
> 
> Perhaps:
> 
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.
> 
> J.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

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.



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.



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
  organisations, or unauthorised staff in list-member organisations,
  from obtaining the embargoed materials.

  The Xen Project provides the mailing list
     xen-security-issues-discuss@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.


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


-- 

Re: Security policy ambiguities - XSA-108 process post-mortem

[John Haxby]

On 10/11/14 18:01, Ian Jackson wrote:
>     * Domain name(s) which you use to provide Xen software/services.

This makes sense for a services provider but I'm not sure what it means
for a distro.   Is this intended to mean a download location for an
installation image and updates?    If it's a download location wouldn't
a URL make more sense?

jch

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
<ijackson@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-discuss@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

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > III. Information-sharing
> > ========================
...
> >   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"

Thanks.

> I take it in general the technical measures you envision is pgp / gpg?

No, I don't (honestly) expect anything that sophisticated.  I meant
that eg website downloads ought to be password protected.  We should
give that as an example.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@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 ?

I would say, give it a week for further feedback and then prepare a patch.

I do have one question. What led us to publish an XSA number on 
http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
CVE numbers are not published normally and we don't publish them 
until after the embargo due to CVE rules. The reason why I am asking 
is that one of the main reasons for the heightened media attention we 
got during XSA 108, is because the media were able to correlate 
statements related to an undisclosed security fix being responsible 
for the AWS reboot, with the information on http://xenbits.xen.org/xsa/ 

If this kind of correlation was not possible, this might remove media
speculation in future and reduce pressure on Xen users.

I am wondering what community members view on publish XSA 
numbers post embargo only? Of course this would impact what
can be disclosed pre-embargo.

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

However, I find the text somewhat confusing. "may deploy fixed 
versions during  the embargo, only with permission from the 
Security Team" contradicts the other statements, that deploying 
fixes is OK, unless stated in the  advisory text. 

Or did I misinterpret? 

In any case, it is not quite clear what the protocol to get permission 
is. Or whether, the protocol is "deployment is OK" unless stated 
otherwise.

So I think, in the final policy text this should be written from the 
viewpoint of a pre-disclosure member, not the viewpoint of the 
Security Team.

Or is the intention that permission is sought via
xen-security-issues-discuss@lists.xenproject.org? 

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

It's either that, or we periodically review applications and see whether
they need to be improved. Given that the list is public, over time
there will be a list of templates that have been accepted which can
serve as examples.

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

Do you anticipate that the list be moderated?

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

As it is a public list, I am assuming that others on the list may be
allowed to post concerns on the list. 

>  If you are dissatisfied with the Security Team's decision you may
>  appeal it via the Xen Project's governance processes.

It is not quite clear how this would work in practice. Are you 
suggesting that the referee process would be used in this case?
That would be that fundamentally, maintainers, project leads, ...
would need to look at appeals.

I suppose that would be OK and in reality, we will hardly ever
get appeals.


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

+1


> IV. Fixes which seem to have rough consensus as they were
> =========================================================
> 
> (Reproduced unchanged from my previous proposed wording:)
+1

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I do have one question. What led us to publish an XSA number on 
> http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
> CVE numbers are not published normally and we don't publish them 
> until after the embargo due to CVE rules.

We used to publish CVEs in advance but MITRE asked us to stop doing
so.

We publish the XSA numbers because the purpose of the secrecy is to
prevent vulnerabilities being exploited.  The purpose of the secrecy
is not the convenience of the Security Team.  Everything that does not
need to be secret for that real purpose should be public.

Keeping secret the existence of an XSA number, and its embargo date,
would not improve the security of systems running Xen.  So we should
not do that.

Making the embargo end date public is very useful for people who are
_not_ on the predisclosure list, because it means that they can plan
their response.  (And it wouldn't make much sense to publish embargo
end date(s) without XSA numbers.)

> I am wondering what community members view on publish XSA 
> numbers post embargo only? Of course this would impact what
> can be disclosed pre-embargo.

Another impact of keeping things totally secret in the way you suggest
is that service providers would no longer be able to give honest
reasons for maintenance activity.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 14 Nov 2014, at 12:50, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> I do have one question. What led us to publish an XSA number on 
>> http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell, 
>> CVE numbers are not published normally and we don't publish them 
>> until after the embargo due to CVE rules.
> 
> We used to publish CVEs in advance but MITRE asked us to stop doing
> so.
> 
> We publish the XSA numbers because the purpose of the secrecy is to
> prevent vulnerabilities being exploited.  The purpose of the secrecy
> is not the convenience of the Security Team.  Everything that does not
> need to be secret for that real purpose should be public.
> 
> Keeping secret the existence of an XSA number, and its embargo date,
> would not improve the security of systems running Xen.  So we should
> not do that.
> 
> Making the embargo end date public is very useful for people who are
> _not_ on the predisclosure list, because it means that they can plan
> their response.  (And it wouldn't make much sense to publish embargo
> end date(s) without XSA numbers.)

That is a good explanation and I can live with it.
I was mainly asking, because MITRE asked us to remove CVE numbers and there seemed to be some inconsistency

> 
>> I am wondering what community members view on publish XSA 
>> numbers post embargo only? Of course this would impact what
>> can be disclosed pre-embargo.
> 
> Another impact of keeping things totally secret in the way you suggest
> is that service providers would no longer be able to give honest
> reasons for maintenance activity.

That is also true

Regards
Lars

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
...
> >  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
> 
> However, I find the text somewhat confusing. "may deploy fixed 
> versions during  the embargo, only with permission from the 
> Security Team" contradicts the other statements, that deploying 
> fixes is OK, unless stated in the  advisory text. 

I will clarify my proposed wording on this point.

> In any case, it is not quite clear what the protocol to get permission 
> is. Or whether, the protocol is "deployment is OK" unless stated 
> otherwise.
> 
> So I think, in the final policy text this should be written from the 
> viewpoint of a pre-disclosure member, not the viewpoint of the 
> Security Team.
> 
> Or is the intention that permission is sought via
> xen-security-issues-discuss@lists.xenproject.org? 

No, the permission will be stated in the advisory.  I have reworded
this in my copy of my draft text to make this clearer.

Thanks,
Ian.

[PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I would say, give it a week for further feedback and then prepare a patch.

It's been rather longer than a week - sorry.

I would like to propose the following series of changes to the Xen
Project Security Policy.  For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

You can find the git tree I am using here:
  http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h=refs/heads/rebasing
The relevant changes are in master..rebasing.

I have put a copy of the bare HTML here:
  http://xenbits.xen.org/people/iwj/draft/security_vulnerability_process.html

The substance of each change is discussed in the corresponding commit
message.

Ian.

[PATCH SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice

[Ian Jackson]

No semantic change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 7069646..4ed0042 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -246,7 +246,7 @@ advisories. Please include in the e-mail:</p>
 or have not sent a statement that they have read this policy and will
 abide by, it will be asked to do so. </p>
 <p>Organisations should not request subscription via the mailing list
-web interface, any such subscription requests will be rejected and
+web interface.  Any such subscription requests will be rejected and
 ignored.</p>
 <p>A role address (such
 as <a href="mailto:security@example.com">security@example.com</a>)
-- 
1.7.10.4

[PATCH SECURITY-POLICY 2/9] Add headings

[Ian Jackson]

 - For Predisclosure list application process
 - For Handling of embargoed information"

No semantic change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 4ed0042..010cf76 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -186,6 +186,7 @@ addresses.)</p>
 of the advisory and patches, with a clearly marked embargo date, as
 soon as they are available. The pre-disclosure list will also receive
 copies of public advisories when they are first issued or updated</p>
+<h3>Handling of embargoed information</h3>
 <p>Organizations on the pre-disclosure list are expected to maintain
 the confidentiality of the vulnerability up to the embargo date which
 security@xenproject have agreed with the discoverer, and are
@@ -214,6 +215,7 @@ following:</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
+<h3>Predisclosure list membership application process</h3>
 <p>Organisations who meet the criteria should contact
 security@xenproject if they wish to receive pre-disclosure of
 advisories. Please include in the e-mail:</p>
-- 
1.7.10.4

[PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Jackson]

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.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
   <li>The assigned XSA number</li>
   <li>The planned disclosure date</li>
 </ul>
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo.  Permission for
+deployment, and any restrictions, will be stated in the embargoed
+advisory text.</p>
+<p>The Security Team will normally permit such deployment, even for
+systems where VMs are managed or used by non-members of the
+predisclosure list.  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.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
-- 
1.7.10.4

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Jan Beulich]

>>> On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -212,6 +212,17 @@ following:</p>
>    <li>The assigned XSA number</li>
>    <li>The planned disclosure date</li>
>  </ul>
> +<p>List members may, if (and only if) the Security Team grants
> +permission, deploy fixed versions during the embargo.  Permission for

..., may deploy ... ?

Jan

> +deployment, and any restrictions, will be stated in the embargoed
> +advisory text.</p>
> +<p>The Security Team will normally permit such deployment, even for
> +systems where VMs are managed or used by non-members of the
> +predisclosure list.  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.</p>
>  <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
>  permitted to also make available the allocated CVE number. This is no
>  longer permitted in accordance with MITRE policy.</p>

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Lars Kurth]

On 19 Jan 2015, at 10:20, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
>> +<p>List members may, if (and only if) the Security Team grants
>> +permission, deploy fixed versions during the embargo.  Permission for
> 
> 

Better: List members may deploy fixed versions during the embargo, if (...)
Lars

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission"):
> On 19 Jan 2015, at 10:20, Jan Beulich <JBeulich@suse.com> wrote:
> > On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
> >> +<p>List members may, if (and only if) the Security Team grants
> >> +permission, deploy fixed versions during the embargo.  Permission for
> 
> Better: List members may deploy fixed versions during the embargo, if (...)

The reason I didn't write it like that is that someone who reads only
the first part of the sentence might not see the caveat.

Is my wording unclear ?

Ian.

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Campbell]

On Mon, 2015-01-19 at 13:38 +0000, Ian Jackson wrote:
> Lars Kurth writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission"):
> > On 19 Jan 2015, at 10:20, Jan Beulich <JBeulich@suse.com> wrote:
> > > On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
> > >> +<p>List members may, if (and only if) the Security Team grants
> > >> +permission, deploy fixed versions during the embargo.  Permission for
> > 
> > Better: List members may deploy fixed versions during the embargo, if (...)
> 
> The reason I didn't write it like that is that someone who reads only
> the first part of the sentence might not see the caveat.

Yes, I think having that very important restriction front and centre is
a good thing.

> Is my wording unclear ?

Not to me, fwiw.

Ian.

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[George Dunlap]

On Mon, Jan 19, 2015 at 1:38 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Lars Kurth writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission"):
>> On 19 Jan 2015, at 10:20, Jan Beulich <JBeulich@suse.com> wrote:
>> > On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
>> >> +<p>List members may, if (and only if) the Security Team grants
>> >> +permission, deploy fixed versions during the embargo.  Permission for
>>
>> Better: List members may deploy fixed versions during the embargo, if (...)
>
> The reason I didn't write it like that is that someone who reads only
> the first part of the sentence might not see the caveat.
>
> Is my wording unclear ?

I think it's just a less common grammatical construct (splitting "may
do X" into "may, if Y, do X"), and so perhaps a bit more difficult for
non-native speakers to parse?  But I think that probably in this case,
while it might take a bit more effort to read for some, the risk of
someone actually misunderstanding your wording is low; while the risk
of someone missing the caveat in the other wording is much more
dangerous.  So I'd leave it the way it is.

 -George

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Lars Kurth]

Agree with George

On 19 Jan 2015, at 15:55, George Dunlap <george.dunlap@eu.citrix.com> wrote:

> On Mon, Jan 19, 2015 at 1:38 PM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
>> Lars Kurth writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission"):
>>> On 19 Jan 2015, at 10:20, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
>>>>> +<p>List members may, if (and only if) the Security Team grants
>>>>> +permission, deploy fixed versions during the embargo.  Permission for
>>> 
>>> Better: List members may deploy fixed versions during the embargo, if (...)
>> 
>> The reason I didn't write it like that is that someone who reads only
>> the first part of the sentence might not see the caveat.
>> 
>> Is my wording unclear ?
> 
> I think it's just a less common grammatical construct (splitting "may
> do X" into "may, if Y, do X"), and so perhaps a bit more difficult for
> non-native speakers to parse?  But I think that probably in this case,
> while it might take a bit more effort to read for some, the risk of
> someone actually misunderstanding your wording is low; while the risk
> of someone missing the caveat in the other wording is much more
> dangerous.  So I'd leave it the way it is.
> 
> -George

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Campbell]

On Mon, 2015-01-19 at 10:20 +0000, Jan Beulich wrote:
> >>> On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
> > --- a/security_vulnerability_process.html
> > +++ b/security_vulnerability_process.html
> > @@ -212,6 +212,17 @@ following:</p>
> >    <li>The assigned XSA number</li>
> >    <li>The planned disclosure date</li>
> >  </ul>
> > +<p>List members may, if (and only if) the Security Team grants
> > +permission, deploy fixed versions during the embargo.  Permission for
> 
> ..., may deploy ... ?

The may is before the first comma, which is where it should be I think.
(Lars' suggestion to reword entirely notwithstanding)

Ian.

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Jan Beulich]

>>> On 19.01.15 at 13:36, <Ian.Campbell@citrix.com> wrote:
> On Mon, 2015-01-19 at 10:20 +0000, Jan Beulich wrote:
>> >>> On 16.01.15 at 20:52, <ijackson@chiark.greenend.org.uk> wrote:
>> > --- a/security_vulnerability_process.html
>> > +++ b/security_vulnerability_process.html
>> > @@ -212,6 +212,17 @@ following:</p>
>> >    <li>The assigned XSA number</li>
>> >    <li>The planned disclosure date</li>
>> >  </ul>
>> > +<p>List members may, if (and only if) the Security Team grants
>> > +permission, deploy fixed versions during the embargo.  Permission for
>> 
>> ..., may deploy ... ?
> 
> The may is before the first comma, which is where it should be I think.
> (Lars' suggestion to reword entirely notwithstanding)

Indeed, but I noticed this only when seeing Lars' reply. Sorry
for the noise.

Jan

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Campbell]

On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> 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.
> 
> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  security_vulnerability_process.html |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
> index 010cf76..de5e83e 100644
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -212,6 +212,17 @@ following:</p>
>    <li>The assigned XSA number</li>
>    <li>The planned disclosure date</li>
>  </ul>
> +<p>List members may, if (and only if) the Security Team grants
> +permission, deploy fixed versions during the embargo.  Permission for
> +deployment, and any restrictions, will be stated in the embargoed
> +advisory text.</p>

Do you have a corresponding patch to our advisory template to add a
section with an XXX for this?

> +<p>The Security Team will normally permit such deployment, even for
> +systems where VMs are managed or used by non-members of the
> +predisclosure list.  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.</p>
>  <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
>  permitted to also make available the allocated CVE number. This is no
>  longer permitted in accordance with MITRE policy.</p>

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission"):
> On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> > +<p>List members may, if (and only if) the Security Team grants
> > +permission, deploy fixed versions during the embargo.  Permission for
> > +deployment, and any restrictions, will be stated in the embargoed
> > +advisory text.</p>
> 
> Do you have a corresponding patch to our advisory template to add a
> section with an XXX for this?

No, but it's trivial.  I think, though, that perhaps I should go
through this series and add an `implementation tasks' note to each
commit message.

Ian.

Re: [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Campbell]

On Mon, 2015-01-19 at 13:08 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission"):
> > On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> > > +<p>List members may, if (and only if) the Security Team grants
> > > +permission, deploy fixed versions during the embargo.  Permission for
> > > +deployment, and any restrictions, will be stated in the embargoed
> > > +advisory text.</p>
> > 
> > Do you have a corresponding patch to our advisory template to add a
> > section with an XXX for this?
> 
> No, but it's trivial.  I think, though, that perhaps I should go
> through this series and add an `implementation tasks' note to each
> commit message.

Good idea.

Ian.

[PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Jackson]

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de5e83e..4fd02e9 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -228,8 +228,9 @@ permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
 <h3>Predisclosure list membership application process</h3>
 <p>Organisations who meet the criteria should contact
-security@xenproject if they wish to receive pre-disclosure of
-advisories. Please include in the e-mail:</p>
+predisclosure-applications@xenproject if they wish to receive
+pre-disclosure of advisories.  That is a public mailing list.
+<p>Please include in the e-mail:</p>
 <ul>
   <li>The name of your organization</li>
   <li>A brief description of why you fit the criteria, along with
-- 
1.7.10.4

Re: [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Campbell]

On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  security_vulnerability_process.html |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
> index de5e83e..4fd02e9 100644
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -228,8 +228,9 @@ permitted to also make available the allocated CVE number. This is no
>  longer permitted in accordance with MITRE policy.</p>
>  <h3>Predisclosure list membership application process</h3>
>  <p>Organisations who meet the criteria should contact
> -security@xenproject if they wish to receive pre-disclosure of
> -advisories. Please include in the e-mail:</p>
> +predisclosure-applications@xenproject if they wish to receive
                                        ^.org

> +pre-disclosure of advisories.  That is a public mailing list.

s/That/This/? Not sure.

> +<p>Please include in the e-mail:</p>
>  <ul>
>    <li>The name of your organization</li>
>    <li>A brief description of why you fit the criteria, along with

Re: [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications."):
> On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> > -security@xenproject if they wish to receive pre-disclosure of
> > -advisories. Please include in the e-mail:</p>
> > +predisclosure-applications@xenproject if they wish to receive
>                                         ^.org

Deliberately omitted to try to help avoid spam.  I could leave it in
but bear in mind that that list needs to be open for posting to all
(even non-subscribers).

> > +pre-disclosure of advisories.  That is a public mailing list.
> 
> s/That/This/? Not sure.

I thought `that' because the message itself (and the policy) isn't on
a mailing list.

Ian.

Re: [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Campbell]

On Mon, 2015-01-19 at 13:10 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications."):
> > On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> > > -security@xenproject if they wish to receive pre-disclosure of
> > > -advisories. Please include in the e-mail:</p>
> > > +predisclosure-applications@xenproject if they wish to receive
> >                                         ^.org
> 
> Deliberately omitted to try to help avoid spam.  I could leave it in
> but bear in mind that that list needs to be open for posting to all
> (even non-subscribers).

Perhaps if it were "<a href=mailto:"'d up it would help?

I don't think it will be all that clear to non-involved people reading
this (especially if they are in a panic) what suffix they need to add.

Or include "<dot> org", since that seems to be a pretty common syntax.

> > > +pre-disclosure of advisories.  That is a public mailing list.
> > 
> > s/That/This/? Not sure.
> 
> I thought `that' because the message itself (and the policy) isn't on
> a mailing list.

It sounds weird to me (not to say it's wrong of course...).

Perhaps:

...@xenproject, which is a public mailing list, if they wish ...

or, "Note that this is a public mailing list"?

Ian.

Re: [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Don Koch]

On Mon, 19 Jan 2015 13:19:03 +0000
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Mon, 2015-01-19 at 13:10 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications."):
> > > On Fri, 2015-01-16 at 19:52 +0000, Ian Jackson wrote:
> > > > -security@xenproject if they wish to receive pre-disclosure of
> > > > -advisories. Please include in the e-mail:</p>
> > > > +predisclosure-applications@xenproject if they wish to receive
> > >                                         ^.org
> > 
> > Deliberately omitted to try to help avoid spam.  I could leave it in
> > but bear in mind that that list needs to be open for posting to all
> > (even non-subscribers).
> 
> Perhaps if it were "<a href=mailto:"'d up it would help?

Sounds like a bigger sign post for spammers to me.

> I don't think it will be all that clear to non-involved people reading
> this (especially if they are in a panic) what suffix they need to add.
> 
> Or include "<dot> org", since that seems to be a pretty common syntax.

I'd go with this or something similar.

-d

Re: [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications."):
> Perhaps:
> ...@xenproject, which is a public mailing list, if they wish ...
> or, "Note that this is a public mailing list"?

I went with the former of those (using parens rather than commas).

Ian.

[PATCH SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application

[Ian Jackson]

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.

Also remove the "case-by-case-basis" membership exception.  This is
not consistent with the new objective membership application process.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |   79 ++++++++++++++++++++++++-----------
 1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 4fd02e9..41b5fe0 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -176,9 +176,7 @@ development, is very likely to be accepted; whereas a project with a
 single developer who spends a few hours a month will most likey be
 rejected.</p>
 <p>For organizational users, a rule of thumb is that "large scale"
-means an installed base of 300,000 or more Xen guests. Other
-well-established organisations with a mature security response process
-will be considered on a case-by-case basis.</p>
+means an installed base of 300,000 or more Xen guests.</p>
 <p>The list of entities on the pre-disclosure list is public. (Just
 the list of projects and organisations, not the actual email
 addresses.)</p>
@@ -230,35 +228,66 @@ longer permitted in accordance with MITRE policy.</p>
 <p>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.
-<p>Please include in the e-mail:</p>
+<p>You must include in the e-mail:</p>
 <ul>
   <li>The name of your organization</li>
-  <li>A brief description of why you fit the criteria, along with
-  evidence to support the claim</li>
-  <li>A security alias e-mail address (no personal addresses -- see
-  below)</li>
-  <li>A link to a web page with your security policy statement</li>
+  <li>Domain name(s) which you use to provide Xen software/services</li>
+  <li>A brief description of why you fit the criteria</li>
+  <li>If not all of your products/services use Xen, a list of (some
+  of) your products/services (or categories thereof) which do.</li>
+  <li>Link(s) to current public web pages, belonging to your
+  organisation, for each of following pieces of information:
+    <ul>
+      <li>Evidence of your status as a service/software provider:
+        <ul>
+          <li>If you are a public hosting provider, your public rates
+          or how to get a quote</li>
+          <li>If you are a software provider, how your
+          software can be downloaded or purchased</li>
+          <li>If you are an open-source project, a mailing list
+          archive and/or version control repository, with
+          active development</li>
+        </ul>
+      </li>
+      <li>Evidence of your status as a user/distributor of Xen:
+        <ul>
+          <li>Statements about, or descriptions of, your eligible
+          production services or released software, from which it is
+          immediately evident that they use Xen.
+        </ul>
+      </li>
+      <li>Information about your handling of security problems:
+        <ul>
+          <li>Your invitation to members of the public, who discover
+          security problems with your products/services, to report
+          them in confidence to you;
+          <li>Specifically, the contact information (email addresses or
+          other contact instructions) which such a member of the
+          public should use.
+        </ul>
+      </li>
+    </ul>
+    <p>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.</p>
+    <p>If the pages are long and/or PDFs are involved, your email
+    should say which part of the pages and documents are relevant.</p>
+  </li>
   <li>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 to regarding confidentiality during an embargo
   period</li>
-  <li>Evidence that will be considered may include the following:
-    <ul>
-      <li>If you are a public hosting provider, a link to a web page
-      with your public rates</li>
-      <li>If you are a software provider, a link to a web page where
-      your software can be downloaded or purchased</li>
-      <li>If you are an open-source project, a link to a mailing list
-      archive and/or a version control repository demonstrating active
-      development</li>
-      <li>A public key signed with a key which is in the PGP "strong
-      set"</li>
-    </ul>
-  </li>
+  <li>The single (non-personal) email alias you wish added to the
+  predisclosure list.</li>
 </ul>
-<p>Organizations already on the list who do not have a security alias
-or have not sent a statement that they have read this policy and will
-abide by, it will be asked to do so. </p>
+<p>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.</p>
+<p>If you are dissatisfied with the Security Team's decision you may
+appeal it via the Xen Project's governance processes.</p>
 <p>Organisations should not request subscription via the mailing list
 web interface.  Any such subscription requests will be rejected and
 ignored.</p>
-- 
1.7.10.4

[PATCH SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo

[Ian Jackson]

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 41b5fe0..d1d40ca 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -224,6 +224,27 @@ situations are expected to be rare.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
+<h3>Information-sharing amongst predisclosure list members</h3>
+<p>Predisclosure 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.</p>
+<p>The Xen Project provides the mailing list
+<code>xen-security-issues-discuss@lists.xenproject.org</code>
+for this purpose.  List members are encouraged to use it but
+may share with other list members' security teams via other
+channels.</p>
+<p>The <code>-discuss</code> list's distribution is identical to that of the primary
+predisclosure list <code>xen-security-issues</code>.  Recipient organisations who
+do not wish to receive all of the traffic on -discuss should use
+recipient-side email filtering based on the provided <code>List-Id</code>.</p>
+<p>The <code>-discuss</code> 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.</p>
 <h3>Predisclosure list membership application process</h3>
 <p>Organisations who meet the criteria should contact
 predisclosure-applications@xenproject if they wish to receive
-- 
1.7.10.4

[PATCH SECURITY-POLICY 7/9] Clarify and fix prior consultation text

[Ian Jackson]

The prior consultation clause should applies to all disclosure
exceptions.  The list end appears to have been moved by mistake.  So
put it back.

Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure list members.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index d1d40ca..2d7c43e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -200,9 +200,10 @@ partners:</p>
   <li>the impact, scope, set of vulnerable systems or the nature of
   the vulnerability</li>
   <li>revision control commits which are a fix for the problem</li>
-  <li>patched software (even in binary form) without prior
-  consultation with security@xenproject and/or the discoverer.</li>
+  <li>patched software (even in binary form)</li>
 </ul>
+without prior
+consultation with security@xenproject.
 <p>List members are allowed to make available to their users only the
 following:</p>
 <ul>
-- 
1.7.10.4

[PATCH SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users

[Ian Jackson]

Service provider list members should not be prevented from being
reasonably honest with their users.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 2d7c43e..d6e0df5 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -222,6 +222,14 @@ 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.</p>
+<p>Where the list member is a service provider who intends to take
+disruptive action such as rebooting as part of deploying a fix: 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).
+This applies whether the deployment occurs during the embargo (with
+permission - see above) or is planned for after the end of the
+embargo.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
-- 
1.7.10.4

[PATCH SECURITY-POLICY 9/9] Document changes in changelog and heading

[Ian Jackson]

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index d6e0df5..df52221 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -1,6 +1,6 @@
 <p>This document has come in effect in December 2011 and will be
 reviewed periodically (see revision sections). The last modification
-has been made in October 2014.</p>
+has been made in (approval date tbd).</p>
 <h2>Introduction</h2>
 <p>Computer systems have bugs. Currently recognised best practice for
 bugs with security implications is to notify significant downstream
@@ -384,6 +384,8 @@ email addresses or internal business groups).</p>
 <h2>Change History</h2>
 <div class="box-note">
   <ul>
+    <li><strong>v3.0 (approval date TBD):</strong> New predisclosure list application
+    process and information-sharing and -handling rules; and, minor clarifications.</li>
     <li><strong>v2.7 Oct 21st 2014:</strong> Added the following
     vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File
     Sanctuary, iWeb Technologies Inc., Memset</li>
-- 
1.7.10.4

[PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem

[Jan Beulich]

>>> On 16.01.15 at 20:48, <ijackson@chiark.greenend.org.uk> wrote:
> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 
> process post-mortem"):
>> I would say, give it a week for further feedback and then prepare a patch.
> 
> It's been rather longer than a week - sorry.
> 
> I would like to propose the following series of changes to the Xen
> Project Security Policy.  For readability I have presented them as
> diffs to a reasonably-plausibly-formatted HTML.

LGTM, but I think there's no point in ack-ing the series as the
changes need to be voted on anyway.

One thing I'm missing though is some statement regarding the
handling of existing list members when the policy changes (while
the agreement given by them during the application process was
only for an earlier version).

Jan

[PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Jan Beulich writes ("[Xen-devel] [PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem"):
> LGTM, but I think there's no point in ack-ing the series as the
> changes need to be voted on anyway.

Indeed.

I will post a v2 with the minor fixes from this thread incorporated.

> One thing I'm missing though is some statement regarding the
> handling of existing list members when the policy changes (while
> the agreement given by them during the application process was
> only for an earlier version).

I don't think this is necessary in this case.  The questions which are
explicitly addressed in the policy now are almost all (a)
clarifications of things which were unclear before and which in the
past the Security Team have had to answer, and (b) resolved in a
permissive way.

The exception is the possibility that deployment of a particular fix
would be forbidden.  But if that were to arise, it would be stated
clearly in the advisory text.  I don't think we need to explicitly
invite predisclosure list members to agree to such a statement, given
the vagueness of the existing policy.

I have deliberately not included a requalification process in this
series of changes.  I would like to leave that to a later update.

Ian.

Re: [PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 19 Jan 2015, at 13:36, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Jan Beulich writes ("[Xen-devel] [PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem"):
>> LGTM, but I think there's no point in ack-ing the series as the
>> changes need to be voted on anyway.
> 
> Indeed.
> 
> I will post a v2 with the minor fixes from this thread incorporated.
Agreed

Lars

Re: [PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Fri, Jan 16, 2015 at 7:48 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> I would say, give it a week for further feedback and then prepare a patch.
>
> It's been rather longer than a week - sorry.
>
> I would like to propose the following series of changes to the Xen
> Project Security Policy.  For readability I have presented them as
> diffs to a reasonably-plausibly-formatted HTML.
>
> You can find the git tree I am using here:
>   http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h=refs/heads/rebasing
> The relevant changes are in master..rebasing.

FWIW I've talken a look at it and it all seems good.

 -George

[PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

I would like to propose the following series of changes to the Xen
Project Security Policy.  For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

The substance of each change is discussed in the corresponding commit
message.

I am going to wait a week to see if anyone has any further comments.
If not, I will ask the Xen Project Community Manager to conduct the
formal approval process.


You can find the git tree I am using here:
  http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h\
=refs/heads/rebasing
The relevant changes are in master..rebasing.

I have put a copy of the bare HTML here:
  http://xenbits.xen.org/people/iwj/draft/security_vulnerability_process.html


This is v2 of the series of changes.  The only comments were minor and
technical, and have (I think) been addressed.  The changes in v2 of the
series compared to my previous patch-series proposal:
 * Add IMPLEMENTATION TASKS section to various of the commit messages
 * Minor wording changes (no semantic change compared to v1)
 * Better presentation of email addresses (no semantic change)

Thanks,
Ian.

[PATCH v2 SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice

[Ian Jackson]

No semantic change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 7069646..4ed0042 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -246,7 +246,7 @@ advisories. Please include in the e-mail:</p>
 or have not sent a statement that they have read this policy and will
 abide by, it will be asked to do so. </p>
 <p>Organisations should not request subscription via the mailing list
-web interface, any such subscription requests will be rejected and
+web interface.  Any such subscription requests will be rejected and
 ignored.</p>
 <p>A role address (such
 as <a href="mailto:security@example.com">security@example.com</a>)
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 2/9] Add headings

[Ian Jackson]

 - For Predisclosure list application process
 - For Handling of embargoed information"

No semantic change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 4ed0042..010cf76 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -186,6 +186,7 @@ addresses.)</p>
 of the advisory and patches, with a clearly marked embargo date, as
 soon as they are available. The pre-disclosure list will also receive
 copies of public advisories when they are first issued or updated</p>
+<h3>Handling of embargoed information</h3>
 <p>Organizations on the pre-disclosure list are expected to maintain
 the confidentiality of the vulnerability up to the embargo date which
 security@xenproject have agreed with the discoverer, and are
@@ -214,6 +215,7 @@ following:</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
+<h3>Predisclosure list membership application process</h3>
 <p>Organisations who meet the criteria should contact
 security@xenproject if they wish to receive pre-disclosure of
 advisories. Please include in the e-mail:</p>
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 3/9] Deployment with Security Team Permission

[Ian Jackson]

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.

IMPLEMENTATION TASKS:
 * Add new section to Security Team's advisory template.
 * Add new section to any existing outstanding embargoed advisories.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
   <li>The assigned XSA number</li>
   <li>The planned disclosure date</li>
 </ul>
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo.  Permission for
+deployment, and any restrictions, will be stated in the embargoed
+advisory text.</p>
+<p>The Security Team will normally permit such deployment, even for
+systems where VMs are managed or used by non-members of the
+predisclosure list.  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.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications.

[Ian Jackson]

IMPLEMENTATION TASKS:
 * Create the mailing list (and check that it works from outside)

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

---
v2: Provide whole email address for predisclosure-applications@,
    but obfuscate it with <dot> and a <span>.
    Reword sentence about public mailing list as suggested by
    Ian Campbell.
---
 security_vulnerability_process.html |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de5e83e..8870f8d 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -228,8 +228,10 @@ permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
 <h3>Predisclosure list membership application process</h3>
 <p>Organisations who meet the criteria should contact
-security@xenproject if they wish to receive pre-disclosure of
-advisories. Please include in the e-mail:</p>
+predisclosure-applications@xenproject&lt;d<span>ot</span>&gt;org
+(which is a public mailing list) if they wish to receive
+pre-disclosure of advisories.
+<p>Please include in the e-mail:</p>
 <ul>
   <li>The name of your organization</li>
   <li>A brief description of why you fit the criteria, along with
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application

[Ian Jackson]

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.

Also remove the "case-by-case-basis" membership exception.  This is
not consistent with the new objective membership application process.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |   79 ++++++++++++++++++++++++-----------
 1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 8870f8d..de8fd44 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -176,9 +176,7 @@ development, is very likely to be accepted; whereas a project with a
 single developer who spends a few hours a month will most likey be
 rejected.</p>
 <p>For organizational users, a rule of thumb is that "large scale"
-means an installed base of 300,000 or more Xen guests. Other
-well-established organisations with a mature security response process
-will be considered on a case-by-case basis.</p>
+means an installed base of 300,000 or more Xen guests.</p>
 <p>The list of entities on the pre-disclosure list is public. (Just
 the list of projects and organisations, not the actual email
 addresses.)</p>
@@ -231,35 +229,66 @@ longer permitted in accordance with MITRE policy.</p>
 predisclosure-applications@xenproject&lt;d<span>ot</span>&gt;org
 (which is a public mailing list) if they wish to receive
 pre-disclosure of advisories.
-<p>Please include in the e-mail:</p>
+<p>You must include in the e-mail:</p>
 <ul>
   <li>The name of your organization</li>
-  <li>A brief description of why you fit the criteria, along with
-  evidence to support the claim</li>
-  <li>A security alias e-mail address (no personal addresses -- see
-  below)</li>
-  <li>A link to a web page with your security policy statement</li>
+  <li>Domain name(s) which you use to provide Xen software/services</li>
+  <li>A brief description of why you fit the criteria</li>
+  <li>If not all of your products/services use Xen, a list of (some
+  of) your products/services (or categories thereof) which do.</li>
+  <li>Link(s) to current public web pages, belonging to your
+  organisation, for each of following pieces of information:
+    <ul>
+      <li>Evidence of your status as a service/software provider:
+        <ul>
+          <li>If you are a public hosting provider, your public rates
+          or how to get a quote</li>
+          <li>If you are a software provider, how your
+          software can be downloaded or purchased</li>
+          <li>If you are an open-source project, a mailing list
+          archive and/or version control repository, with
+          active development</li>
+        </ul>
+      </li>
+      <li>Evidence of your status as a user/distributor of Xen:
+        <ul>
+          <li>Statements about, or descriptions of, your eligible
+          production services or released software, from which it is
+          immediately evident that they use Xen.
+        </ul>
+      </li>
+      <li>Information about your handling of security problems:
+        <ul>
+          <li>Your invitation to members of the public, who discover
+          security problems with your products/services, to report
+          them in confidence to you;
+          <li>Specifically, the contact information (email addresses or
+          other contact instructions) which such a member of the
+          public should use.
+        </ul>
+      </li>
+    </ul>
+    <p>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.</p>
+    <p>If the pages are long and/or PDFs are involved, your email
+    should say which part of the pages and documents are relevant.</p>
+  </li>
   <li>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 to regarding confidentiality during an embargo
   period</li>
-  <li>Evidence that will be considered may include the following:
-    <ul>
-      <li>If you are a public hosting provider, a link to a web page
-      with your public rates</li>
-      <li>If you are a software provider, a link to a web page where
-      your software can be downloaded or purchased</li>
-      <li>If you are an open-source project, a link to a mailing list
-      archive and/or a version control repository demonstrating active
-      development</li>
-      <li>A public key signed with a key which is in the PGP "strong
-      set"</li>
-    </ul>
-  </li>
+  <li>The single (non-personal) email alias you wish added to the
+  predisclosure list.</li>
 </ul>
-<p>Organizations already on the list who do not have a security alias
-or have not sent a statement that they have read this policy and will
-abide by, it will be asked to do so. </p>
+<p>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.</p>
+<p>If you are dissatisfied with the Security Team's decision you may
+appeal it via the Xen Project's governance processes.</p>
 <p>Organisations should not request subscription via the mailing list
 web interface.  Any such subscription requests will be rejected and
 ignored.</p>
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo

[Ian Jackson]

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.

IMPLEMENTATION TASKS:
 * Send a notification to the existing predisclosure list members
   informing them that they have been subscribed to the new list.
   Notice should point them to the policy section on filtering
   by List-Id, and offer to unsubscribe them from both lists if
   they prefer.
 * Create the new mailing list, and
   - check that it can be emailed from outside
   - that messages are held for moderation and can be approved

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

---
v2: Obfuscate -discuss@ list's full email address with <dot>
    and <span>.
---
 security_vulnerability_process.html |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de8fd44..2d32e51 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -224,6 +224,27 @@ situations are expected to be rare.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
+<h3>Information-sharing amongst predisclosure list members</h3>
+<p>Predisclosure 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.</p>
+<p>The Xen Project provides the mailing list
+<code>xen-security-issues-discuss@lists.xenproject&lt;do<span>t&gt;</span>org</code>
+for this purpose.  List members are encouraged to use it but
+may share with other list members' security teams via other
+channels.</p>
+<p>The <code>-discuss</code> list's distribution is identical to that of the primary
+predisclosure list <code>xen-security-issues</code>.  Recipient organisations who
+do not wish to receive all of the traffic on -discuss should use
+recipient-side email filtering based on the provided <code>List-Id</code>.</p>
+<p>The <code>-discuss</code> 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.</p>
 <h3>Predisclosure list membership application process</h3>
 <p>Organisations who meet the criteria should contact
 predisclosure-applications@xenproject&lt;d<span>ot</span>&gt;org
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 7/9] Clarify and fix prior consultation text

[Ian Jackson]

The prior consultation clause should applies to all disclosure
exceptions.  The list end appears to have been moved by mistake.  So
put it back.

Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure list members.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 2d32e51..7412652 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -200,9 +200,10 @@ partners:</p>
   <li>the impact, scope, set of vulnerable systems or the nature of
   the vulnerability</li>
   <li>revision control commits which are a fix for the problem</li>
-  <li>patched software (even in binary form) without prior
-  consultation with security@xenproject and/or the discoverer.</li>
+  <li>patched software (even in binary form)</li>
 </ul>
+without prior
+consultation with security@xenproject.
 <p>List members are allowed to make available to their users only the
 following:</p>
 <ul>
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users

[Ian Jackson]

Service provider list members should not be prevented from being
reasonably honest with their users.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 7412652..3b9c1ba 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -222,6 +222,14 @@ 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.</p>
+<p>Where the list member is a service provider who intends to take
+disruptive action such as rebooting as part of deploying a fix: 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).
+This applies whether the deployment occurs during the embargo (with
+permission - see above) or is planned for after the end of the
+embargo.</p>
 <p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
 permitted to also make available the allocated CVE number. This is no
 longer permitted in accordance with MITRE policy.</p>
-- 
1.7.10.4

[PATCH v2 SECURITY-POLICY 9/9] Document changes in changelog and heading

[Ian Jackson]

IMPLEMENTATION TASKS:
 * Assign last change date to be approval date
 * Reformat html to web page CMS format
 * Update web page

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 security_vulnerability_process.html |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 3b9c1ba..9ca7622 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -1,6 +1,6 @@
 <p>This document has come in effect in December 2011 and will be
 reviewed periodically (see revision sections). The last modification
-has been made in October 2014.</p>
+has been made in (approval date tbd).</p>
 <h2>Introduction</h2>
 <p>Computer systems have bugs. Currently recognised best practice for
 bugs with security implications is to notify significant downstream
@@ -385,6 +385,8 @@ email addresses or internal business groups).</p>
 <h2>Change History</h2>
 <div class="box-note">
   <ul>
+    <li><strong>v3.0 (approval date TBD):</strong> New predisclosure list application
+    process and information-sharing and -handling rules; and, minor clarifications.</li>
     <li><strong>v2.7 Oct 21st 2014:</strong> Added the following
     vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File
     Sanctuary, iWeb Technologies Inc., Memset</li>
-- 
1.7.10.4

Re: [PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Ian Jackson writes ("[PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem"):
> I would like to propose the following series of changes to the Xen
> Project Security Policy.  For readability I have presented them as
> diffs to a reasonably-plausibly-formatted HTML.
...
> I am going to wait a week to see if anyone has any further comments.
> If not, I will ask the Xen Project Community Manager to conduct the
> formal approval process.

Lars, can you please conduct the formal approval process for this set
of changes.

Regards,
Ian.

Re: [PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

Sure,
when I get into the office
Lars

On 2 Feb 2015, at 17:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:

> Ian Jackson writes ("[PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem"):
>> I would like to propose the following series of changes to the Xen
>> Project Security Policy.  For readability I have presented them as
>> diffs to a reasonably-plausibly-formatted HTML.
> ...
>> I am going to wait a week to see if anyone has any further comments.
>> If not, I will ask the Xen Project Community Manager to conduct the
>> formal approval process.
> 
> Lars, can you please conduct the formal approval process for this set
> of changes.
> 
> Regards,
> Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Thu, Oct 9, 2014 at 12:06 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> 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@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.
>
> (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.

+1.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Jan Beulich]

>>> On 09.10.14 at 01:06, <ijackson@chiark.greenend.org.uk> wrote:
>> 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.

I can see the benefits of allowing sharing, but I can also see
downsides: Along with the set of pre-disclosure list members
growing, allowing an increased amount of interchange
(including binaries) increases the risk of a leak. And since
us monitoring what is being exchanged would not be workable
in my opinion, it is also clear that it would be purely incidental
for us (or anyone else) to notice such a leak.

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

I'm not sure about this fairness aspect. Yes, distro consumers can
apply to become a list member on their own (which I personally
dislike, but that's what the community wanted last time round).
But they're then still at the mercy of that distro provider, i.e. by
the time fixed packages get produced and internally tested, the
embargo may be over. In particular this would seem to increase
fairness only between equal size distro providers; smaller ones
may get further disadvantage from that due to their more limited
bandwidth of producing/testing/distributing fixes.

Therefore I would favor only first party consumers to be eligible
to join the list, and no early deployments being permitted at all.

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

The noise such occasionally (as in the case that triggered this
discussion) may create certainly doesn't help the processing of
an issue "behind the scenes" (i.e. embargoed). Yes, we do
ourselves publish the embargo expiry, but maybe we should
instead reconsider doing so rather than allowing everyone to
widely announce issues (even if indirectly), resulting in all kinds
of speculation?

>> Predisclosure list memembership

This whole final section I completely agree with.

There's one more thing I thought of btw: When we change the
policy following whatever community input we gathered (not just
now, but also in the future), people currently on the pre-disclosure
list may (at least theoretically) end up no longer qualifying for
being on the list. Shouldn't we
- add some kind of statement to the effect of implicit agreement
  to changed terms,
- provide means for list members to be removed other than by
  them asking for it?

Jan

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Fri, Oct 10, 2014 at 3:47 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 09.10.14 at 01:06, <ijackson@chiark.greenend.org.uk> wrote:
>>> 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.
>
> I can see the benefits of allowing sharing, but I can also see
> downsides: Along with the set of pre-disclosure list members
> growing, allowing an increased amount of interchange
> (including binaries) increases the risk of a leak. And since
> us monitoring what is being exchanged would not be workable
> in my opinion, it is also clear that it would be purely incidental
> for us (or anyone else) to notice such a leak.
>
>> 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.
>
> I'm not sure about this fairness aspect. Yes, distro consumers can
> apply to become a list member on their own (which I personally
> dislike, but that's what the community wanted last time round).
> But they're then still at the mercy of that distro provider, i.e. by
> the time fixed packages get produced and internally tested, the
> embargo may be over. In particular this would seem to increase
> fairness only between equal size distro providers; smaller ones
> may get further disadvantage from that due to their more limited
> bandwidth of producing/testing/distributing fixes.

On the other hand, small distros can enlist the help of other people
on the list to help produce / test fixes.  XenServer has a massive
testing framework that can be used to make sure there aren't any
accidental regressions before they publish a patch; I assume SuSE and
Oracle have something similar.  But how much testing bandwidth does
Debian have for security fixes?  At the moment CentOS doesn't have an
automated framework: all testing for the XSA-108 update had to happen
by hand.  Being able to bring in people on the list using the
xen4centos packages would have been helpful.

 -George

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 10 Oct 2014, at 16:47, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>> Predisclosure list memembership
> 
> This whole final section I completely agree with.
> 
> There's one more thing I thought of btw: When we change the
> policy following whatever community input we gathered (not just
> now, but also in the future), people currently on the pre-disclosure
> list may (at least theoretically) end up no longer qualifying for
> being on the list. Shouldn't we
> - add some kind of statement to the effect of implicit agreement
>  to changed terms,
> - provide means for list members to be removed other than by
>  them asking for it?
> 
> Jan

I also was wondering whether it would make sense to put a time-limit on applications. For example, we could say that processing an application will take 2 weeks. By doing so, we avoid having to handle applications as a response to media speculation. If we get an application wrong, and allow somebody wrong on the list who then discloses information related to an embargo, we would create risks for others already on the list. This would be the worst possible outcome for the project. Just a thought

Regards
Lars

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I also was wondering whether it would make sense to put a time-limit
> on applications. For example, we could say that processing an
> application will take 2 weeks. By doing so, we avoid having to
> handle applications as a response to media speculation. If we get an
> application wrong, and allow somebody wrong on the list who then
> discloses information related to an embargo, we would create risks
> for others already on the list. This would be the worst possible
> outcome for the project. Just a thought

I can see that this is attractive, but on the other hand I think it
was very useful to the Xen community as a whole, that members were
able to join /during/ the last furore.  I think having an artificial
delay would generate ill-feeling.

Since IMO there should be clear objective criteria, these applications
should be routine, and we shouldn't have too much trouble with them.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[James Bulpin]

Jan Beulich writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
>
> I can see the benefits of allowing sharing, but I can also see
> downsides: Along with the set of pre-disclosure list members
> growing, allowing an increased amount of interchange
> (including binaries) increases the risk of a leak. And since
> us monitoring what is being exchanged would not be workable
> in my opinion, it is also clear that it would be purely incidental
> for us (or anyone else) to notice such a leak.

It's a risk but I think the benefit of having far fewer vulnerable
systems in production by the time the vulnerability is publically
disclosed outweighs the risk. Today we have a 100% probability that
there will be large numbers of vulnerable systems the day the
embargo is lifted.
 
> > 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.
> 
> I'm not sure about this fairness aspect. Yes, distro consumers can
> apply to become a list member on their own (which I personally
> dislike, but that's what the community wanted last time round).
> But they're then still at the mercy of that distro provider, i.e. by
> the time fixed packages get produced and internally tested, the
> embargo may be over. In particular this would seem to increase
> fairness only between equal size distro providers; smaller ones
> may get further disadvantage from that due to their more limited
> bandwidth of producing/testing/distributing fixes.
> 
> Therefore I would favor only first party consumers to be eligible
> to join the list, and no early deployments being permitted at all.

I view fairness here as providing a level playing field for all
concerned. If we do allow sharing then it doesn't mandate that
distros will provide fixes ahead of the embargo being lifted but
allows them to do so if they wish. Each distro can chose its own
policy without artificial constraint.

Cheers,
James

-- 
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> There's one more thing I thought of btw: When we change the
> policy following whatever community input we gathered (not just
> now, but also in the future), people currently on the pre-disclosure
> list may (at least theoretically) end up no longer qualifying for
> being on the list. Shouldn't we
> - add some kind of statement to the effect of implicit agreement
>   to changed terms,
> - provide means for list members to be removed other than by
>   them asking for it?

Perhaps the right approach is to have a requalification process, where
each member's predisclosure list membership is reviewed periodically.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Campbell]

On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
> 
>   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.

While I appreciate where you are coming from I don't think it is the
place of this policy to rail against the crapitude of the modern web and
try and enforce our own standards on things (much as I would like too).

I don't think it is unreasonable to expect that members of the security
team who typically run a browser with this crud disabled (which includes
myself) would load up their special sandboxed/throwaway browser with a
default config when faced with this sort of thing.

That said, the bits about accessibility seem less unreasonable, on the
basis that its not beyond the realms of possibility that someone
processing an application might not have the option of turning off a
screenreader etc.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Matt Wilson]

On Tue, Oct 21, 2014 at 01:32:46PM +0100, Ian Campbell wrote:
> On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
> > 
> >   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.
> 
> While I appreciate where you are coming from I don't think it is the
> place of this policy to rail against the crapitude of the modern web and
> try and enforce our own standards on things (much as I would like too).
> 
> I don't think it is unreasonable to expect that members of the security
> team who typically run a browser with this crud disabled (which includes
> myself) would load up their special sandboxed/throwaway browser with a
> default config when faced with this sort of thing.
> 
> That said, the bits about accessibility seem less unreasonable, on the
> basis that its not beyond the realms of possibility that someone
> processing an application might not have the option of turning off a
> screenreader etc.

Due to travel last week for LinuxCon EU and Linux Plumbers Conference
I've not been able to put together a reply to all the points raised a
the start of this thread.

On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

This process works quite well for the distros email list, where
requests for membership requests are discussion on oss-security (a
public list). Protecting embargoed details should be our primary
concern here, and every time we increase the distribution of this
information we are increasing the risk it will leak. This deserves a
rigorous public debate, not a decision made under fire or undue
pressure.

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2012-07/msg00122.html
[2] http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg03085.html

Re: Security policy ambiguities - XSA-108 process post-mortem

[Jan Beulich]

>>> On 21.10.14 at 16:31, <msw@linux.com> wrote:
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.

And indeed I had intended to bring this point up too, but then forgot.
So - thanks for raising this!

Jan

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.

I agree that publishing applications, and the team's responses, would
be a jolly good idea.  I am 100% opposed, though, to any kind of
non-objective `community consensus' process.

Such a system would (a) be unworkable in practice, because no-one
really cares about this kind of tedious makework, and (b) at serious
risk of favouritism (or its opposite).

> This process works quite well for the distros email list, where
> requests for membership requests are discussion on oss-security (a
> public list). [...]

I don't want to criticise another community's process, but I strongly
feel that our arrangements should have broad eligibility based on
objective criteria.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> On this point in particular, back in 2012 [1] I suggested that all
>> membership requests should be discussed in public on a community email
>> list like xen-devel, or another email list to avoid noise. The Xen
>> Project Security Team shouldn't have to evaluate petitions for
>> membership while managing an embargoed issue. I brought this up again
>> in 2013 [2] regarding the Coverity process.
>
> I agree that publishing applications, and the team's responses, would
> be a jolly good idea.  I am 100% opposed, though, to any kind of
> non-objective `community consensus' process.
>
> Such a system would (a) be unworkable in practice, because no-one
> really cares about this kind of tedious makework, and (b) at serious
> risk of favouritism (or its opposite).

"It's opposite" meaning, "We all hate company X, so let's not let them
join the list"?

>> This process works quite well for the distros email list, where
>> requests for membership requests are discussion on oss-security (a
>> public list). [...]
>
> I don't want to criticise another community's process, but I strongly
> feel that our arrangements should have broad eligibility based on
> objective criteria.

Having black-and-white rules is nice and simple and safe; but in most
reasonably "rich" domains, it's very difficult to come up with simple,
objective criteria that cover all situations satisfactorily.  This is
true in morality and law; my guess is that it's true here as well.

But I'd be willing to take a look at such a list; maybe I'm wrong
about how objective we can make things. :-)

 -George

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
> > Such a system would (a) be unworkable in practice, because no-one
> > really cares about this kind of tedious makework, and (b) at serious
> > risk of favouritism (or its opposite).
> 
> "It's opposite" meaning, "We all hate company X, so let's not let them
> join the list"?

Yes.

> > I don't want to criticise another community's process, but I strongly
> > feel that our arrangements should have broad eligibility based on
> > objective criteria.
> 
> Having black-and-white rules is nice and simple and safe; but in most
> reasonably "rich" domains, it's very difficult to come up with simple,
> objective criteria that cover all situations satisfactorily.  This is
> true in morality and law; my guess is that it's true here as well.
> 
> But I'd be willing to take a look at such a list; maybe I'm wrong
> about how objective we can make things. :-)

I think the spirit behind our previous criteria is objective.  The
problem we had was just that the rules didn't specify enough about the
*form of the predisclosure list application*.

That's why my proposed change doesn't actually touch the criteria part
of the policy.  It just formalises the application process.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
> >   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.
> 
> While I appreciate where you are coming from I don't think it is the
> place of this policy to rail against the crapitude of the modern web and
> try and enforce our own standards on things (much as I would like too).
> 
> I don't think it is unreasonable to expect that members of the security
> team who typically run a browser with this crud disabled (which includes
> myself) would load up their special sandboxed/throwaway browser with a
> default config when faced with this sort of thing.

I don't think members of the security team should be expected to
either (a) set up a parallel sandboxed web browsing infrastructure,
and keep that sandbox highly available so that it can be used during a
security crisis, or (b) expose themselves to attacks of various kinds.

The security list is very different to most of the situations where I
am currently expecting to use my crud-enabled browser (as you so aptly
put it).  At the moment I use my crud-enabled browser when I am
expecting to spend money, or engage with organisations that I already
have a relationship with.  That is, where I have already made a
decision to trust the entity whose webshite I'm trying to look at.

I am not personally willing to take random URLs sent to me in email
from strangers and simply visit them in my usual crud-enabled browser
- the same browser I use for my internet banking.  I do have a
*sandboxed* crud-enabled browser but it lives at home on a machine
which has restricted access to and from the rest of my network - and I
certainly wouldn't want to try to let it display on my Trusted
Computing Base.

I think that people who want to be on the predisclosure list should
make matters easy for the security team.  I think it therefore is only
fair to say that an application might be delayed if the team member
who happens to deal with the application can't conveniently access the
evidence that the applicant is supposed to provide.

And that an application might be rejected entirely if insufficiently
many members of the team are able to access, and hence verify, the
information provided.


Or to put it another way: if the Xen Project community decides to
reject an explicit statement along the lines I propose above, that
won't mean that I will put my own security and privacy at risk when
dealing with predisclosure list applications.

So those applications might be delayed anyway, unless other members of
the team want to take up the slack.  Of course if the community
doesn't like my attitude, they're free to get rid of me.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Matt Wilson]

On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:

[...]

> I think that people who want to be on the predisclosure list should
> make matters easy for the security team.  I think it therefore is only
> fair to say that an application might be delayed if the team member
> who happens to deal with the application can't conveniently access the
> evidence that the applicant is supposed to provide.

I think that we should reduce any burden on the security team by
making this a community decision that is discussed in public, rather
than something that is handled exclusively in a closed manner as it is
today. This way others who are active community participants can help
with the decision making process can do the investigation and weigh in
on the risk/benefit tradeoff to the security process and the
project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
or [1] if you are willing to visit a URL. ;-)

There's been a bit of talk about "delay" and so on. I'd rather not set
expectations on how long the processing a petition to be added to the
predisclosure list should take. Building community consensus takes
time, just as it does for other activities like getting a patch
applied. I don't think that this process needs to be different.

> And that an application might be rejected entirely if insufficiently
> many members of the team are able to access, and hence verify, the
> information provided.
> 
> 
> Or to put it another way: if the Xen Project community decides to
> reject an explicit statement along the lines I propose above, that
> won't mean that I will put my own security and privacy at risk when
> dealing with predisclosure list applications.
>
> So those applications might be delayed anyway, unless other members of
> the team want to take up the slack.  Of course if the community
> doesn't like my attitude, they're free to get rid of me.

I believe that others would be happy to take up the slack, but they
may not be members of the security team. I'd rather the security team
be able to focus on the matters of preparing fixes and managing
security embargoes, and not have to spend precious time on this aspect
of the policy.

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2014-10/threads.html#02532

Re: Security policy ambiguities - XSA-108 process post-mortem

[George Dunlap]

On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
> On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:
>
> [...]
>
>> I think that people who want to be on the predisclosure list should
>> make matters easy for the security team.  I think it therefore is only
>> fair to say that an application might be delayed if the team member
>> who happens to deal with the application can't conveniently access the
>> evidence that the applicant is supposed to provide.
>
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
>
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for other activities like getting a patch
> applied. I don't think that this process needs to be different.

We might remove some of the (potential) pressure to rush things by
saying that once approved, new members will not receive information
about *currently embargoed* disclosures, but only about *future*
disclosures.

I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
policy) they wouldn't have been eligible to receive XSA-108 anyway.

But perhaps that would be too unpopular to actually implement...

 -George

Re: Security policy ambiguities - XSA-108 process post-mortem

[Matt Wilson]

On Mon, Nov 03, 2014 at 11:37:23AM +0000, George Dunlap wrote:
> On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
[...]
> > There's been a bit of talk about "delay" and so on. I'd rather not set
> > expectations on how long the processing a petition to be added to the
> > predisclosure list should take. Building community consensus takes
> > time, just as it does for other activities like getting a patch
> > applied. I don't think that this process needs to be different.
> 
> We might remove some of the (potential) pressure to rush things by
> saying that once approved, new members will not receive information
> about *currently embargoed* disclosures, but only about *future*
> disclosures.
> 
> I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
> policy) they wouldn't have been eligible to receive XSA-108 anyway.
> 
> But perhaps that would be too unpopular to actually implement...

The decision making mechanics aside, that makes sense to me.

--msw

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Campbell]

On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
> 
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for

I think regardless of who is processing the applications what is more
important is to have a concrete set of *objective* criteria. Anyone who
demonstrates that they meet those criteria must be allowed to join.

It reads to me as if you are instead are proposing that the community
apply some sort of subjective standard of risk/benefit tradeoffs and
building consensus about a new membership. I think to take that approach
(whether in public or private) would be against the previous steer from
the community that the list should be fairly widely inclusive -- there
will naturally be a tendency for those already inside the system to be
more conservative about allowing others to join (since it increases
their risk) and so they will tend (not even deliberately) to
overestimate the risk of allowing new memberships.

In the light of the discussions around sharing amongst predisclosure
list members and pre-embargo deployment I think the inclusive nature of
the list is an important balancing factor in the inherent disparity
between distro style consumers and service providers.

If we do not continue take an inclusive approach to the list membership
then my opinion on the matter of sharing and predeploying will be very
different.

>  other activities like getting a patch
> applied. I don't think that this process needs to be different.

I don't think this analogy is useful. It is rare that someone who has
had a patch accepted has any incentive to prevent another essentially
unrelated patch from being applied. Also, many of the reasons for not
taking a patch are subjective (coding style, taste, disagreements about
design issues, etc).

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
>> I think that we should reduce any burden on the security team by
>> making this a community decision that is discussed in public, rather
>> than something that is handled exclusively in a closed manner as it is
>> today. This way others who are active community participants can help
>> with the decision making process can do the investigation and weigh in
>> on the risk/benefit tradeoff to the security process and the
>> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
>> or [1] if you are willing to visit a URL. ;-)
>> 
>> There's been a bit of talk about "delay" and so on. I'd rather not set
>> expectations on how long the processing a petition to be added to the
>> predisclosure list should take. Building community consensus takes
>> time, just as it does for
> 
> I think regardless of who is processing the applications what is more
> important is to have a concrete set of *objective* criteria. Anyone who
> demonstrates that they meet those criteria must be allowed to join.

I don't think that having applications discussed and processed on a dedicated public list and objective criteria are mutually exclusive. The two may provide a good balance, and allow for some flexibility in ambiguous cases. 

In particular if we either have a strong owner or follow the "two +1 with no -1" model of a set of decision makers who earned that status over time. More or less what we use for access to Coverity Scan output. 

Regards
Lars

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Campbell]

On Thu, 2014-11-06 at 16:01 +0000, Lars Kurth wrote:
> On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> >> I think that we should reduce any burden on the security team by
> >> making this a community decision that is discussed in public, rather
> >> than something that is handled exclusively in a closed manner as it is
> >> today. This way others who are active community participants can help
> >> with the decision making process can do the investigation and weigh in
> >> on the risk/benefit tradeoff to the security process and the
> >> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> >> or [1] if you are willing to visit a URL. ;-)
> >> 
> >> There's been a bit of talk about "delay" and so on. I'd rather not set
> >> expectations on how long the processing a petition to be added to the
> >> predisclosure list should take. Building community consensus takes
> >> time, just as it does for
> > 
> > I think regardless of who is processing the applications what is more
> > important is to have a concrete set of *objective* criteria. Anyone who
> > demonstrates that they meet those criteria must be allowed to join.
> 
> I don't think that having applications discussed and processed on a
> dedicated public list and objective criteria are mutually exclusive.

I didn't say otherwise. In fact I said the opposite.

My concern was about the criteria being objective and not subjective,
regardless of who is processing them.

Nobody should be doing a "risk/benefit tradeoff to the security process
and the project" when processing an application. They should be going
through a list ticking boxes to show that the applicant has(n't) met
various criteria.

Ian.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Bastian Blank]

On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote:
>   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.

Why do you think such a hypotetical list needs to be moderated?

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

Why this constraint to "who are service providers"?

> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
>   The Security Team has no discretion to accept applications which do
>   not provide all of the information required above.

Is there are particular reason why do you want to restrict them?

Bastian

-- 
You!  What PLANET is this!
		-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Re: Security policy ambiguities - XSA-108 process post-mortem

[James Bulpin]

Bastian Blank writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
> >   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.
> 
> Why this constraint to "who are service providers"?

+1

We already have a definition of eligibility for membership of the
pre-disclosure list and therefore I don't think it is necessary or
desirable to further constrain specific privileges to subsets of the
list members.

Cheers,
James

-- 
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Bastian Blank writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote:
> >   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.
> 
> Why do you think such a hypotetical list needs to be moderated?

Good question.  Primarily because I anticipate two potential failure
modes:

1. People posting non-password-protected URLs, or the like.  If the
   list is moderated we can notice this quickly and hopefully have
   things taken down.

2. Predisclosure list members using the embargoed-information-sharing
   forum as a venue for political consensus-building, planning, and
   pressurising.

Of these I am most worried about the 2nd.

We have already suffered from a few very dramatic incidents, where
predisclosure list members used their privileged informational
position to try to gain advantage in policymaking and policy
interpretation.

The idea that the predisclosure list members are somehow the most
proper or most real stakeholders and that it is their opinion which
ought to count is distressingly prevalent - especially, it appears,
amongst some of the senior management of some predisclosure list
members.  When a security crisis is in full swing, such management
often becomes involved.  As I say we have had multiple occasions
where intense political pressure was applied.

It would be a very bad idea to explicitly provide a forum which
predisclosure list members - whose interests are ill-aligned with
those of the public at large - could use for confidential lobbying,
political coordination, and networking.  (It might even be illegal;
private collusion by predisclosure list members to manipulate
policymaking might well sometimes be illegal in any case.)

If the list is to be unmoderated, at the very least, we would need an
automatic mechanism which would publish all of the exchanges on a
particular issue at the end of its embargo.  ATM we don't have
software to do that.


> >   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.
> 
> Why this constraint to "who are service providers"?

Thanks for pointing out this problem.

This was not intended to be a constraint; it was intended to mean
`_even_ those who are service providers'.  Since it was previously
`obvious' that people with private Xen deployments can deploy fixes
when they get them.

I will make a revised proposal for wording in this area.


> > The Security Team should be forbidden from trying to hunt down
> > eligibility information etc. and should instead be mandated to reject
> > incomplete requests.
> >   The Security Team has no discretion to accept applications which do
> >   not provide all of the information required above.
> 
> Is there are particular reason why do you want to restrict them?

As a member of the Security Team I would like to be able to say `sorry
your application did not qualify'.  I don't want to have to say `sorry
your application didn't quite meet the criteria and we have chosen not
to exercise our discretion'.

Thanks,
Ian.

Security policy ambiguities - XSA-108 process post-mortem

[Ian Campbell]

create ^
thanks

Initial post wasn't bcc-d to the bug tracker.

Processed: Security policy ambiguities - XSA-108 process post-mortem

[xen]

Processing commands for xen@bugs.xenproject.org:

> create ^
Created new bug #44 rooted at `<21557.24142.873029.148164@mariner.uk.xensource.com>'
Title: `Security policy ambiguities - XSA-108 process post-mortem'
> thanks
Finished processing.

Modified/created Bugs:
 - 44: http://bugs.xenproject.org/xen/bug/44 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

Re: Security policy ambiguities - XSA-108 process post-mortem

[James Bulpin]

Xen Project Security Team writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
>
> It is (still!) ambiguous whether predisclosure list members may share
> fixes and other information with other predisclosure list members.  We
> intended to fix this ambiguity following the XSA-7 discussion but
> the policy was never updated.
> 
> During the XSA-108 embargo the Security Team were asked whether this
> permitted; we concluded that since we had said `yes' last time, and
> documented this in the XSA-7 postmortem, and the community had failed
> to change the policy, we should probably say `yes' again.
> 
> The community should formally correct this ambiguity.

I would like to see it explicitly permitted for predisclosure list members
to share source and binary fixes along with impact and mitigation
information with each other. The latter is important as a Xen distributor
may wish to interpret the raw information in terms more meaningful to
that distributor's users (for example if the distributor's product hides
PV/HVM/etc virt mode behind templates then that distributor may wish to
inform its users which templates are impacted rather than the more raw
form of (e.g.) "PV guests").

> [snip]
> 
> Deployment on public systems of fixed versions during embargo
> =============================================================
> 
> It is ambiguous whether the wording above prohibits deployment by a
> service provider of patched hosting software running customer VMs.
> Some predisclosure list members thought that this was prohibited;
> others thought that it was permitted and accordingly deployed the
> XSA-108 fix during the embargo.
> 
> This question should be resolved, clearly, one way or the other.

I would like to see it explicitly permitted for _any_ predisclosure
list member to deploy a fix on production systems before the embargo
is lifted. However there should be an "exception" mechanism for the
(hopefully uncommon) case that such a deployment would create an
unacceptably high probability of the details of the vulnerability
being discoverable. This exception mechanism would be used based on
the judgement of the Security Team with post-mortems used to provide
feedback on this decision making if necessary.

Cheers,
James

-- 
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Tim Deegan]

At 13:27 +0000 on 29 Oct (1414585666), James Bulpin wrote:
> Xen Project Security Team writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> > [snip]
> >
> > It is (still!) ambiguous whether predisclosure list members may share
> > fixes and other information with other predisclosure list members.  We
> > intended to fix this ambiguity following the XSA-7 discussion but
> > the policy was never updated.
> > 
> > During the XSA-108 embargo the Security Team were asked whether this
> > permitted; we concluded that since we had said `yes' last time, and
> > documented this in the XSA-7 postmortem, and the community had failed
> > to change the policy, we should probably say `yes' again.
> > 
> > The community should formally correct this ambiguity.
> 
> I would like to see it explicitly permitted for predisclosure list members
> to share source and binary fixes along with impact and mitigation
> information with each other. The latter is important as a Xen distributor
> may wish to interpret the raw information in terms more meaningful to
> that distributor's users (for example if the distributor's product hides
> PV/HVM/etc virt mode behind templates then that distributor may wish to
> inform its users which templates are impacted rather than the more raw
> form of (e.g.) "PV guests").
> 
> > [snip]
> > 
> > Deployment on public systems of fixed versions during embargo
> > =============================================================
> > 
> > It is ambiguous whether the wording above prohibits deployment by a
> > service provider of patched hosting software running customer VMs.
> > Some predisclosure list members thought that this was prohibited;
> > others thought that it was permitted and accordingly deployed the
> > XSA-108 fix during the embargo.
> > 
> > This question should be resolved, clearly, one way or the other.
> 
> I would like to see it explicitly permitted for _any_ predisclosure
> list member to deploy a fix on production systems before the embargo
> is lifted.

I reluctantly agree.

The original purpose (IIRC) of the predisclosure list was to allow
development and testing of fixes to happen in advance of disclosure.
Adding large service providers to the list increased fairness: they
are likely to have modified or wholly custom-built Xen distributions
requiring their own dev & test work, and so would be at a disadvantage
when the vulnerability was disclosed.  Allowing them to _deploy_ in
advance, however, gives them an advantage over non-members -- their
systems are demonstrably more secure.

However, I think that given the community's decision to widen the
predisclosure list as much as it has (so that it now covers basically
any service provider), that advantage goes away.  In which case we
should allow deployment on the grounds that it means fewer unpatched
systems when the embargo expires.

There is a slippery-slope argument here that having such a large list
means that details will inevitably leak, and we might as well save
ourselves all this effort and disclose immediately, but I don't really
believe it. :)  All I'll say for that is that we should be very clear
about the expectation that predisclosure periods will be _short_.

Cheers,

Tim.

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

>>> On 21.10.14 at 16:31, <msw@linux.com> wrote:
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.
Matt,
I don’t have an issue with such an approach, in particular as this is a proven model elsewhere. I would like to understand though how the oss-security process works in practice. Aka how are decisions made, who can join the list, how are conflicts resolved, etc. It seems to me that such a process would be more transparent and also fair. In particular, if we have clear criteria as to what needs to be in place to be eligible.
It seems to me that if we do this, we may need to look at the Project Governance as well, as having a stake in decision making requires maintainer status today. The existing decision making process could easily be used to discuss access related to Coverity. It is not entirely clear to me whether maintainers should have to carry the burden of making decisions on who can join the pre-disclosure list.
Do you expect that maintainers would decide who can join the pre-disclosure list after a public discussion? 
Or is there another group of community members who have earned some kind of credibility to make decisions? And if so, who are they and how is credibility earned? I am assuming that oss-security has developed its own group of distinguished members.
Also, we would need to ensure that requests are not dropped and that the required admin works (adding entities who qualify to the pre-disclosure list as well as adding them to the website).
Best Regards
Lars

Re: Security policy ambiguities - XSA-108 process post-mortem

[Matt Wilson]

On Tue, Oct 21, 2014 at 07:20:28PM +0100, Lars Kurth wrote:
> >>> On 21.10.14 at 16:31, <msw@linux.com> wrote:
> > On this point in particular, back in 2012 [1] I suggested that all
> > membership requests should be discussed in public on a community email
> > list like xen-devel, or another email list to avoid noise. The Xen
> > Project Security Team shouldn't have to evaluate petitions for
> > membership while managing an embargoed issue. I brought this up again
> > in 2013 [2] regarding the Coverity process.
>
> Matt,
>
> I don’t have an issue with such an approach, in particular as this
> is a proven model elsewhere. I would like to understand though how
> the oss-security process works in practice. Aka how are decisions
> made, who can join the list, how are conflicts resolved, etc. It
> seems to me that such a process would be more transparent and also
> fair. In particular, if we have clear criteria as to what needs to
> be in place to be eligible.

Indeed, the criteria for the distros and linux-distros lists are less
completely spelled out compared to the current Xen pre-disclosure
criteria. You have to look through the discussions on oss-security to
see how requests are evaluated. Typically there is a bias toward not
adding new people to the list unless there is a clear justification
through debate. It's much less of a "if you can tick all these boxes"
process and more of a discussion.

Consider this similar to "how do I get my patch applied to the
hypervisor?" You propose a patch, it is debated, and if it is good for
the project it will be applied. It may not be good for the project, in
which case it will not be applied. Some people may say this is unfair,
and that individuals or organizations that get their patches applied
have an advantage over others.

What is the conflict resolution path for "my patch isn't being applied
to upstream Xen"? :-)

> It seems to me that if we do this, we may need to look at the
> Project Governance as well, as having a stake in decision making
> requires maintainer status today. The existing decision making
> process could easily be used to discuss access related to
> Coverity. It is not entirely clear to me whether maintainers should
> have to carry the burden of making decisions on who can join the
> pre-disclosure list.

I believe that strong projects have strong owners. I worry about
projects that fall quickly to making decisions by committee. The "two
+1 with no -1" model that you proposed for Coverity in [1] seems to be
a reasonable balance.

> Do you expect that maintainers would decide who can join the
> pre-disclosure list after a public discussion?

I think this is up for discussion. If the Xen Project community (in
particular, those who do the work) wants to take a voting approach or
an individual maintainer / set of maintainers approach. For the
distros@ list, ultimately I think it comes down to what Alexander (aka
Solar Designer <solar@openwall.com>) decides to do, after being
informed by the debate and overall consensus on the list.

> Or is there another group of community members who have earned some
> kind of credibility to make decisions? And if so, who are they and
> how is credibility earned? I am assuming that oss-security has
> developed its own group of distinguished members.

It has, largely though known individuals who are active in coordinated
security response over the years. Though at the end of the day
Alexander is the one who has to do the changes to the remailer.

> Also, we would need to ensure that requests are not dropped and that
> the required admin works (adding entities who qualify to the
> pre-disclosure list as well as adding them to the website).

I think this is the same as getting a patch applied. Patches get
dropped. People proposing patches send pings. Maintainers get
busy. This is a part of life in working with open source projects. I
think it's best to avoid strict request SLAs, just as we don't have a
"your patch will be applied in 7 days" SLA.

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg02366.html

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

Re: Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth]

On 22 Oct 2014, at 01:41, Matt Wilson <msw@linux.com> wrote:

> On Tue, Oct 21, 2014 at 07:20:28PM +0100, Lars Kurth wrote:
>> 
>> 
>> I don’t have an issue with such an approach, in particular as this
>> is a proven model elsewhere. I would like to understand though how
>> the oss-security process works in practice. Aka how are decisions
>> made, who can join the list, how are conflicts resolved, etc. It
>> seems to me that such a process would be more transparent and also
>> fair. In particular, if we have clear criteria as to what needs to
>> be in place to be eligible.
> 
> Indeed, the criteria for the distros and linux-distros lists are less
> completely spelled out compared to the current Xen pre-disclosure
> criteria. You have to look through the discussions on oss-security to
> see how requests are evaluated. Typically there is a bias toward not
> adding new people to the list unless there is a clear justification
> through debate. It's much less of a "if you can tick all these boxes"
> process and more of a discussion.

The changes on the table are really more practical and aim at demonstrating a) use of Xen and b) a mature security vulnerability process. So I don't think there is a contradiction with having criteria.

> 
> Consider this similar to "how do I get my patch applied to the
> hypervisor?" You propose a patch, it is debated, and if it is good for
> the project it will be applied. It may not be good for the project, in
> which case it will not be applied. Some people may say this is unfair,
> and that individuals or organizations that get their patches applied
> have an advantage over others.
> 
> What is the conflict resolution path for "my patch isn't being applied
> to upstream Xen"? :-)

Maintainer(s) > committer(s) > project lead (> advisory board in some extremely rare circumstances) - in practice however, 99.99% of all issues get resolved at maintainers & committers stage without a vote. I cannot recall an issue where the project lead had to step in as long as I worked with the project and we never had the AB engaged.

To make this work within the existing governance, we would need the equivalent of maintainer(s) > committer(s) > project lead for the pre-disclosure list. We don't have to have a full hierarchy: a project lead makes no sense in this case, or the project lead would just be the Xen HV project lead. If we compare with oss-sec the equivalent of the committer is Alexander. 

So I guess what I am saying is that this is doable, without governance changes.

> 
>> It seems to me that if we do this, we may need to look at the
>> Project Governance as well, as having a stake in decision making
>> requires maintainer status today. The existing decision making
>> process could easily be used to discuss access related to
>> Coverity. It is not entirely clear to me whether maintainers should
>> have to carry the burden of making decisions on who can join the
>> pre-disclosure list.
> 
> I believe that strong projects have strong owners. I worry about
> projects that fall quickly to making decisions by committee. The "two
> +1 with no -1" model that you proposed for Coverity in [1] seems to be
> a reasonable balance.

I stated before that we hardly ever use the voting model for day-to-day activities. Only for process changes, new projects and committer/project lead elections. Personally, I believe that avoiding a formal vote in this case is preferable. 

So the question then would be who would be the owner (aka maintainer and/or committer) of the security pre-disclosure list. The only natural candidates we have right now are members of the Security Team. Of course this may evolve over time, in particular if people who have already a standing in the wider FOSS security community get actively engaged with the process. 

So assuming that someone from the Security Team is willing to step up, and the community agrees, this could be done. But in practice, the burden would still fall onto members of Security Team and all we would change is to create more transparency - at least in the short term. Please do correct me, if you think I am wrong.

>> Also, we would need to ensure that requests are not dropped and that
>> the required admin works (adding entities who qualify to the
>> pre-disclosure list as well as adding them to the website).
> 
> I think this is the same as getting a patch applied. Patches get
> dropped. People proposing patches send pings. Maintainers get
> busy. This is a part of life in working with open source projects. I
> think it's best to avoid strict request SLAs, just as we don't have a
> "your patch will be applied in 7 days" SLA.

That is OK. A bit of a filter on the seriousness of someone requesting to be on the list.

Regards
Lars

Re: Security policy ambiguities - XSA-108 process post-mortem

[Matt Wilson]

On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote:
> 
> On 22 Oct 2014, at 01:41, Matt Wilson <msw@linux.com> wrote:
> 
> > On Tue, Oct 21, 2014 at 07:20:28PM +0100, Lars Kurth wrote:
> >> 
> >> 
> >> I don’t have an issue with such an approach, in particular as this
> >> is a proven model elsewhere. I would like to understand though how
> >> the oss-security process works in practice. Aka how are decisions
> >> made, who can join the list, how are conflicts resolved, etc. It
> >> seems to me that such a process would be more transparent and also
> >> fair. In particular, if we have clear criteria as to what needs to
> >> be in place to be eligible.
> > 
> > Indeed, the criteria for the distros and linux-distros lists are less
> > completely spelled out compared to the current Xen pre-disclosure
> > criteria. You have to look through the discussions on oss-security to
> > see how requests are evaluated. Typically there is a bias toward not
> > adding new people to the list unless there is a clear justification
> > through debate. It's much less of a "if you can tick all these boxes"
> > process and more of a discussion.
> 
> The changes on the table are really more practical and aim at
> demonstrating a) use of Xen and b) a mature security vulnerability
> process. So I don't think there is a contradiction with having
> criteria.

I don't think a) and b) are nearly enough. The bar needs to be set a
lot higher. But this is something we can discuss in a different part
of the thread.

> > Consider this similar to "how do I get my patch applied to the
> > hypervisor?" You propose a patch, it is debated, and if it is good for
> > the project it will be applied. It may not be good for the project, in
> > which case it will not be applied. Some people may say this is unfair,
> > and that individuals or organizations that get their patches applied
> > have an advantage over others.
> > 
> > What is the conflict resolution path for "my patch isn't being applied
> > to upstream Xen"? :-)
> 
> Maintainer(s) > committer(s) > project lead (> advisory board in
> some extremely rare circumstances) - in practice however, 99.99% of
> all issues get resolved at maintainers & committers stage without a
> vote. I cannot recall an issue where the project lead had to step in
> as long as I worked with the project and we never had the AB
> engaged.

I was asking tongue-in-cheek...

Usually things get sorted out through email discussion and a general
consensus is reached. I think we get a bit caught up in defining
parliamentary procedure for situations that rarely, if ever, come up.

> To make this work within the existing governance, we would need the
> equivalent of maintainer(s) > committer(s) > project lead for the
> pre-disclosure list. We don't have to have a full hierarchy: a
> project lead makes no sense in this case, or the project lead would
> just be the Xen HV project lead. If we compare with oss-sec the
> equivalent of the committer is Alexander.

To me, I think that the existing Xen Project meritocracy structure
should work. Those who do the work (i.e., frequent contributors,
maintainers, etc) have shown a commitment to the health and well-being
of the project and the community. I don't think that this needs to be
a function or system that is apart from how the community makes other
decisions.

> So I guess what I am saying is that this is doable, without governance changes.

I think so too.

> >> It seems to me that if we do this, we may need to look at the
> >> Project Governance as well, as having a stake in decision making
> >> requires maintainer status today. The existing decision making
> >> process could easily be used to discuss access related to
> >> Coverity. It is not entirely clear to me whether maintainers should
> >> have to carry the burden of making decisions on who can join the
> >> pre-disclosure list.
> > 
> > I believe that strong projects have strong owners. I worry about
> > projects that fall quickly to making decisions by committee. The "two
> > +1 with no -1" model that you proposed for Coverity in [1] seems to be
> > a reasonable balance.
> 
> I stated before that we hardly ever use the voting model for
> day-to-day activities. Only for process changes, new projects and
> committer/project lead elections. Personally, I believe that
> avoiding a formal vote in this case is preferable.

+1

> So the question then would be who would be the owner (aka maintainer
> and/or committer) of the security pre-disclosure list. The only
> natural candidates we have right now are members of the Security
> Team. Of course this may evolve over time, in particular if people
> who have already a standing in the wider FOSS security community get
> actively engaged with the process.

I think that this may only really matter in cases where someone needs
to referee in the case of lack of consensus.

> So assuming that someone from the Security Team is willing to step
> up, and the community agrees, this could be done. But in practice,
> the burden would still fall onto members of Security Team and all we
> would change is to create more transparency - at least in the short
> term. Please do correct me, if you think I am wrong.

I'm not so sure. I think first we need to have community consensus on
disclosure membership decisions. This is more than transparency, it's
also moving the decision making process into the community. The only
question to me is when there isn't a community consensus, in which
case it seems like the Last Resort mechanisms in the Project
Governance should be a way to remove the burden.

> >> Also, we would need to ensure that requests are not dropped and that
> >> the required admin works (adding entities who qualify to the
> >> pre-disclosure list as well as adding them to the website).
> > 
> > I think this is the same as getting a patch applied. Patches get
> > dropped. People proposing patches send pings. Maintainers get
> > busy. This is a part of life in working with open source projects. I
> > think it's best to avoid strict request SLAs, just as we don't have a
> > "your patch will be applied in 7 days" SLA.
> 
> That is OK. A bit of a filter on the seriousness of someone
> requesting to be on the list.

--msw

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

Re: Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson]

Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Wed, Oct 22, 2014 at 02:05:38PM +0100, Lars Kurth wrote:
> > The changes on the table are really more practical and aim at
> > demonstrating a) use of Xen and b) a mature security vulnerability
> > process. So I don't think there is a contradiction with having
> > criteria.
> 
> I don't think a) and b) are nearly enough. The bar needs to be set a
> lot higher. But this is something we can discuss in a different part
> of the thread.

I agree with Ian Campbell on this topic.  The predisclosure list ought
to remain very broad.  Like Ian, I would give very different answers
to all the other questions, if the membership criteria were narrowed.

Ian.