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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Having gone through the thread, I've prepared a three-part new
> proposal email.
> 
> I. Deployment with Security Team Permission
> II. Predisclosure list memembership
> III. Information sharing
> IV. Fixes which seem to have rough consensus as they were
> 
> Perhaps I should be checking the current web page out as a git tree
> and preparing a patch series ?

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@xxxxxxxxxxxxxxxxxxxx? 

> 
> 
> 
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel