From xen-devel-bounces@lists.xen.org Mon Nov 10 18:11:47 2014
Received: (at maildrop) by bugs.xenproject.org; 10 Nov 2014 18:11:47 +0000
Received: from lists.xen.org ([50.57.142.19])
by bugs.xenproject.org with esmtp (Exim 4.80)
(envelope-from )
id 1XntRL-0008AP-3L
for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 10 Nov 2014 18:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from )
id 1XntHO-0000Nu-M8; Mon, 10 Nov 2014 18:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from ) id 1XntHN-0000Np-Jr
for xen-devel@lists.xenproject.org; Mon, 10 Nov 2014 18:01:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
67/F1-09842-87DF0645; Mon, 10 Nov 2014 18:01:28 +0000
X-Env-Sender: ijackson@chiark.greenend.org.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1415642488!12811415!1
X-Originating-IP: [212.13.197.229]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received:
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18919 invoked from network); 10 Nov 2014 18:01:28 -0000
Received: from chiark.greenend.org.uk (HELO chiark.greenend.org.uk)
(212.13.197.229)
by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
10 Nov 2014 18:01:28 -0000
Received: by chiark.greenend.org.uk (Debian Exim 4.72 #1) with local
(return-path ijackson@chiark.greenend.org.uk)
id 1XntHL-0000NK-Kt; Mon, 10 Nov 2014 18:01:27 +0000
From: Ian Jackson
MIME-Version: 1.0
Message-ID: <21600.64887.416522.656249@chiark.greenend.org.uk>
Date: Mon, 10 Nov 2014 18:01:27 +0000
To: Lars Kurth
Newsgroups: chiark.mail.xen.devel
In-Reply-To:
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
<21557.50031.783473.873273@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Security policy ambiguities - XSA-108
process post-mortem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
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).
--
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel