All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bulpin <James.Bulpin@citrix.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Security policy ambiguities - XSA-108 process	post-mortem
Date: Wed, 29 Oct 2014 13:27:46 +0000	[thread overview]
Message-ID: <817F8DE966913E4D91404CA656535C84113E598A@AMSPEX01CL01.citrite.net> (raw)
In-Reply-To: <21557.24142.873029.148164@mariner.uk.xensource.com>

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.

  parent reply	other threads:[~2014-10-29 13:27 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 15:54 Security policy ambiguities - XSA-108 process post-mortem Xen Project Security Team
2014-10-08 23:06 ` Ian Jackson
2014-10-08 23:55   ` Lars Kurth
2014-10-09  9:37     ` Ian Jackson
2014-10-09 11:24       ` George Dunlap
2014-10-09 16:19         ` Ian Campbell
2014-10-10 14:25         ` Jan Beulich
2014-10-13 12:17           ` George Dunlap
2014-10-29 13:27             ` James Bulpin
2015-01-19 20:36               ` James McKenzie
2015-01-20  8:54                 ` Jan Beulich
2015-01-20 12:29                 ` George Dunlap
2015-02-12 10:44                 ` Lars Kurth
2014-11-10 18:01     ` Ian Jackson
2014-11-11 12:39       ` John Haxby
2014-11-12 18:09       ` George Dunlap
2014-11-13 17:36         ` Ian Jackson
2014-11-14 12:10       ` Lars Kurth
2014-11-14 12:50         ` Ian Jackson
2014-11-14 17:37           ` Lars Kurth
2015-01-16 19:23         ` Ian Jackson
2015-01-16 19:48         ` [PATCH SECURITY-POLICY 0/9] " Ian Jackson
2015-01-16 19:52           ` [PATCH SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 2/9] Add headings Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission Ian Jackson
2015-01-19 10:20               ` Jan Beulich
2015-01-19 11:18                 ` Lars Kurth
2015-01-19 13:38                   ` Ian Jackson
2015-01-19 14:25                     ` Ian Campbell
2015-01-19 15:55                     ` George Dunlap
2015-01-19 19:48                       ` Lars Kurth
2015-01-19 12:36                 ` Ian Campbell
2015-01-19 13:50                   ` Jan Beulich
2015-01-19 12:35               ` Ian Campbell
2015-01-19 13:08                 ` Ian Jackson
2015-01-19 13:10                   ` Ian Campbell
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications Ian Jackson
2015-01-19 12:49               ` Ian Campbell
2015-01-19 13:10                 ` Ian Jackson
2015-01-19 13:19                   ` Ian Campbell
2015-01-19 16:21                     ` Don Koch
2015-01-19 17:57                     ` Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 7/9] Clarify and fix prior consultation text Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 9/9] Document changes in changelog and heading Ian Jackson
2015-01-19 10:29           ` [PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem Jan Beulich
2015-01-19 13:36             ` Ian Jackson
2015-01-19 19:45               ` Lars Kurth
2015-01-19 14:57           ` George Dunlap
2015-01-23 19:31           ` [PATCH v2 SECURITY-POLICY 0/9] " Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 2/9] Add headings Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 3/9] Deployment with Security Team Permission Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 7/9] Clarify and fix prior consultation text Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 9/9] Document changes in changelog and heading Ian Jackson
2015-02-02 17:27             ` [PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem Ian Jackson
2015-02-03  9:49               ` Lars Kurth
2014-10-09 11:09   ` George Dunlap
2014-10-10 14:47   ` Jan Beulich
2014-10-13 11:23     ` George Dunlap
2014-10-13 12:16     ` Lars Kurth
2014-11-10 17:25       ` Ian Jackson
2014-10-29 13:27     ` James Bulpin
2014-11-10 17:21     ` Ian Jackson
2014-10-21 12:32   ` Ian Campbell
2014-10-21 14:31     ` Matt Wilson
2014-10-21 15:06       ` Jan Beulich
2014-11-10 17:29       ` Ian Jackson
2014-11-10 17:39         ` George Dunlap
2014-11-10 18:04           ` Ian Jackson
2014-10-30 11:58     ` Ian Jackson
2014-10-31 22:40       ` Matt Wilson
2014-11-03 11:37         ` George Dunlap
2014-11-03 17:23           ` Matt Wilson
2014-11-05 11:17         ` Ian Campbell
2014-11-06 16:01           ` Lars Kurth
2014-11-10 12:35             ` Ian Campbell
2014-10-22 23:23   ` Bastian Blank
2014-10-29 13:27     ` James Bulpin
2014-11-10 17:42     ` Ian Jackson
2014-10-09  8:29 ` Ian Campbell
2014-10-09  8:45   ` Processed: " xen
2014-10-29 13:27 ` James Bulpin [this message]
2014-10-30 10:51   ` Tim Deegan
2014-10-21 18:20 Lars Kurth
2014-10-22  0:41 ` Matt Wilson
2014-10-22 13:05   ` Lars Kurth
2014-10-22 15:53     ` Matt Wilson
2014-11-10 17:44       ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=817F8DE966913E4D91404CA656535C84113E598A@AMSPEX01CL01.citrite.net \
    --to=james.bulpin@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.