From xen-devel-bounces@lists.xen.org Thu Oct 30 11:01:56 2014
Received: (at maildrop) by bugs.xenproject.org; 30 Oct 2014 11:01:57 +0000
Received: from lists.xen.org ([50.57.142.19])
by bugs.xenproject.org with esmtp (Exim 4.80)
(envelope-from )
id 1XjnUK-00030L-US
for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 30 Oct 2014 11:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from )
id 1XjnKs-0002QM-VR; Thu, 30 Oct 2014 10:52:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
id 1XjnKr-0002Q8-Cn
for xen-devel@lists.xenproject.org; Thu, 30 Oct 2014 10:52:09 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
72/21-02694-85812545; Thu, 30 Oct 2014 10:52:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-31.messagelabs.com!1414666325!12487756!1
X-Originating-IP: [5.39.92.215]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received:
X-StarScan-Version: 6.12.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 30 Oct 2014 10:52:05 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
SMTP; 30 Oct 2014 10:52:05 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
(envelope-from )
id 1XjnKZ-0007Oo-Sp; Thu, 30 Oct 2014 10:51:51 +0000
Date: Thu, 30 Oct 2014 11:51:51 +0100
From: Tim Deegan
To: James Bulpin
Message-ID: <20141030105151.GA25743@deinos.phlegethon.org>
References: <21557.24142.873029.148164@mariner.uk.xensource.com>
<817F8DE966913E4D91404CA656535C84113E598A@AMSPEX01CL01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <817F8DE966913E4D91404CA656535C84113E598A@AMSPEX01CL01.citrite.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Known-Good: Yes
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: tim@xen.org
X-SA-Exim-Scanned: No (on deinos.phlegethon.org);
SAEximRunCond expanded to false
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
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel