All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Security policy ambiguities - XSA-108 process post-mortem
Date: Thu, 9 Oct 2014 12:24:11 +0100	[thread overview]
Message-ID: <CAFLBxZbhmNfaGkYzR9dXB1J2=Vx4qyn=T2NR9Vufu2exy_PW1w@mail.gmail.com> (raw)
In-Reply-To: <21558.22370.175292.5524@chiark.greenend.org.uk>

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

  reply	other threads:[~2014-10-09 11:24 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 [this message]
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
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='CAFLBxZbhmNfaGkYzR9dXB1J2=Vx4qyn=T2NR9Vufu2exy_PW1w@mail.gmail.com' \
    --to=george.dunlap@eu.citrix.com \
    --cc=ijackson@chiark.greenend.org.uk \
    --cc=lars.kurth.xen@gmail.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.