* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:06 ` Ian Jackson
@ 2014-10-08 23:55 ` Lars Kurth
2014-10-09 9:37 ` Ian Jackson
2014-11-10 18:01 ` Ian Jackson
2014-10-09 11:09 ` George Dunlap
` (3 subsequent siblings)
4 siblings, 2 replies; 52+ messages in thread
From: Lars Kurth @ 2014-10-08 23:55 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Xen Project Security Team writes ("Security policy ambiguities - XSA-108 process post-mortem"):
>> We welcome any feedback on our decisions and we look forward to
>> clearer directions from the community.
>
> Here is my own, purely personal, response with answers to the
> questions asked. NB that this is not the opinion of Citrix nor of
> the Xen Project Security Team. But I thought I would at least write
> down something concrete for people to argue about.
>
>
>> Sharing amongst predisclosure list members
>
> I think that the answer should be `yes', in principle. There seems
> little point forbidding this.
>
> Allowing greater sharing would perhaps allow problems with patches to
> be discovered (and the revised patches developed) more easily. We
> should provide a clear channel for collaboration between predisclosure
> list members.
>
> Therefore, the policy should be extended by adding, before
> `Organisations who meet the criteria', the new section:
>
> 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.
>
> (That list obviously doesn't exist yet, but if the policy is approved
> we will create it.)
Ian, this is a very good suggestion.
>
> One reason for permitting this is that we want fairness between
> service providers who use their own versions of Xen, and ones who use
> a version from a software provider. Both kinds of service provider
> should be able to test the fix during the embargo.
>
>
>> Deployment on public systems of fixed versions during embargo
>
> These different understandings have led to some bad feelings - some
> people feel that others have breached the embargo, while they felt
> prevented from acting similarly. This is very regrettable and I
> apologise for my contribution to the unclarity in the policy.
>
> I want to say clearly that I think everyone has acted in good faith.
>
> 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.
b) GPL (or license) compliance - this may be a non-issue, but I would like to get some advice on it.
In the case of XSA 108 both were not an issue, because the hypervisor is not accessible by a user of a cloud provider.
However, if the vulnerability had been in another component this may be different.
> I would
> add, following that list of bullet points:
>
> List members who are service providers may deploy fixed versions
> during the embargo, 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.
I think this does text does not address a) and b)
>
> This question is IMO partly linked to the previous one.
>
>
> 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).
>
>
>> Predisclosure list memembership
>
> The policy should be amended to require applicants to provide the
> information required, in the form of public URLs. The team should not
> be required to judge email aliases or enquire about their recipients
> except to ensure that they don't look like personal aliases.
>
> 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
> security@xenproject if they wish to receive pre-disclosure of
> advisories. 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.
>
> The Security Team has no discretion to accept applications which do
> not provide all of the information required above.
This is a good list.
I do think we should test this though to make sure it actually works. I think there are a few areas which may be ambiguous or not clear enough.
I also think we do need to address websites in non-english languages would be handled. Of course we do not want to discriminate.
>
> Please provide URLs which are accessible and legible on mobile phone
> browsers, which do not require cookies enabled to load, and which
> are useable with text mode browsers, browsers which do not execute
> Javascript, and with screen readers and other accessibility
> software. If the member of the Xen Project Security Team who
> processes your application finds that their usual web browser does
> not display the required information, when presented with the URLs
> in your email, your application might be delayed or even rejected.
>
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:55 ` Lars Kurth
@ 2014-10-09 9:37 ` Ian Jackson
2014-10-09 11:24 ` George Dunlap
2014-11-10 18:01 ` Ian Jackson
1 sibling, 1 reply; 52+ messages in thread
From: Ian Jackson @ 2014-10-09 9:37 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel
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.
> b) GPL (or license) compliance - this may be a non-issue, but I
> would like to get some advice on it.
Feel free to get advice but I can assure you that this is a
non-issue.
> In the case of XSA 108 both were not an issue, because the hypervisor is not accessible by a user of a cloud provider.
> However, if the vulnerability had been in another component this may be different.
If the vulnerability were in a component that were distributed to the
users then 1. the GPL would be engaged 2. my caveat would be violated.
> > List members who are service providers may deploy fixed versions
> > during the embargo, 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.
>
> I think this does text does not address a) and b)
It may be that this wording should be improved since obviously it
isn't clear enough.
> > The Security Team has no discretion to accept applications which do
> > not provide all of the information required above.
>
> This is a good list.
>
> I do think we should test this though to make sure it actually works. I think there are a few areas which may be ambiguous or not clear enough.
It might be worth looking at constructing some some hypothetical or
historical applications and judging them against these criteria.
> I also think we do need to address websites in non-english languages
> would be handled. Of course we do not want to discriminate.
So far, what the security team have done is use online machine
translation services. That seems to have been sufficient so far.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
0 siblings, 2 replies; 52+ messages in thread
From: George Dunlap @ 2014-10-09 11:24 UTC (permalink / raw)
To: Ian Jackson; +Cc: Lars Kurth, xen-devel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-09 11:24 ` George Dunlap
@ 2014-10-09 16:19 ` Ian Campbell
2014-10-10 14:25 ` Jan Beulich
1 sibling, 0 replies; 52+ messages in thread
From: Ian Campbell @ 2014-10-09 16:19 UTC (permalink / raw)
To: George Dunlap; +Cc: Lars Kurth, xen-devel, Ian Jackson
On Thu, 2014-10-09 at 12:24 +0100, George Dunlap wrote:
> 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.
I was wondering about this sort of thing too.
We don't want to leave this up to individual list members, otherwise we
are back in the situation where two members reach different conclusions
and one of them ends up feeling aggrieved. Plus I don't think we can
expect all list members to have the technical understanding to make that
call in the first place.
Ian.
>
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
1 sibling, 1 reply; 52+ messages in thread
From: Jan Beulich @ 2014-10-10 14:25 UTC (permalink / raw)
To: George Dunlap; +Cc: Lars Kurth, xen-devel, Ian Jackson
>>> On 09.10.14 at 13:24, <George.Dunlap@eu.citrix.com> wrote:
> 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.
We're sometimes already struggling determining the set of
consequences a certain issue may have (see statements like
"... cannot be excluded"). I think anticipating what sufficiently
"qualified" people may be able to guess from early deployment
would end up being rather difficult.
Jan
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-10 14:25 ` Jan Beulich
@ 2014-10-13 12:17 ` George Dunlap
2014-10-29 13:27 ` James Bulpin
0 siblings, 1 reply; 52+ messages in thread
From: George Dunlap @ 2014-10-13 12:17 UTC (permalink / raw)
To: Jan Beulich; +Cc: Lars Kurth, xen-devel, Ian Jackson
On 10/10/2014 03:25 PM, Jan Beulich wrote:
>>>> On 09.10.14 at 13:24, <George.Dunlap@eu.citrix.com> wrote:
>> 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.
> We're sometimes already struggling determining the set of
> consequences a certain issue may have (see statements like
> "... cannot be excluded"). I think anticipating what sufficiently
> "qualified" people may be able to guess from early deployment
> would end up being rather difficult.
Perhaps -- but it seems to me to be the least risky of all the alternatives.
As far as I can tell we basically have the following options:
1. Never allow people to deploy during the embargo period.
This eliminates the possibility that someone will be helped to gain
information about the vulnerability by comparing a patched system to an
unpatched one. However, it means that cloud operators may spend a short
amount of time "publicly vulnerable" while they reboot their systems. I
assume it would significantly increase the difficulty of coordinating
such a deployment, as you would have to reboot *all* your servers in the
smallest time window possible, instead of being able to stage it over
several days.
It also increases the temptation for operators to "cheat" by starting
the process a little bit early. This I think could lead to more
significant problems community-wise: with incentive to break the rules,
enforcement becomes an issue -- and I'm sure none of the team want to
have to deal with that.
2. Always allow people to deploy during the embargo period.
This is simple on the security team, and minimizes the "publicly
vulnerable time". It makes deployments easier to coordinate, and avoids
adding an incentive for "bending" the rules.
However, it does in theory allow an attacker the ability to gain
information about the vulnerability by comparing patched systems to
unpatched systems. In practice, the vast majority of the time the
measurable difference in functionality will be like finding a needle in
a haystack; and if the attacker had ever even thought to try the
functionality (e.g., XSA-7), she would have already known about the
bug. But that may not always be the case.
3. Have the security team attempt to evaluate the risk.
This adds work to the security team. But it at least allows the
possibility that, in cases where it's pretty clear that early deployment
*would* give clear hints to an attacker, they could decide to include
deployment in the embargo.
4. Have individual cloud operators evaluate the risk.
This seems like a recipe for disaster.
I think #1 is too risky, particularly from a community perspective. But
maybe I'm being a bit pessimistic.
In my mind, #3 is basically exactly the same as #2, except that in cases
where there would clearly be a problem, the team has an option of
embargoing deployment as well.
I just spent about 10 minutes skimming through the 80 or so XSAs on
http://xenbits.xen.org/xsa/. In most of the cases, it was pretty clear
that the only behavior that changed would be behavior which would
already have clued an attacker into the existence of a potential
vulnerability. For example, in XSA-108, beforehand some reads from the
reserved x2apic range would have returned values whereas now they would
#GP. But if the attacker knew that they returned values, it already
would have occurred to her to see if they returned anything of interest.
I didn't notice a single exception to this, though admittedly I didn't
spend much time looking at it.
This suggests to me that #2 is probably not that dangerous the majority
of the time. It also suggests that there may be a simple criteria that
can be applied for #3 that can eliminate most of the guesswork: Is
anything in the original behavior being changed likely to lead an
attacker to think that there may be a vulnerability there? In the case
of basically all of them, I think the answer there would be "yes".
So at the moment I would favor #3, then #2; I'm not in favor of #1 but I
wouldn't strenuously argue against it. But the main thing is that we
have a clear policy.
-George
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-13 12:17 ` George Dunlap
@ 2014-10-29 13:27 ` James Bulpin
2015-01-19 20:36 ` James McKenzie
0 siblings, 1 reply; 52+ messages in thread
From: James Bulpin @ 2014-10-29 13:27 UTC (permalink / raw)
To: xen-devel
George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
>
> As far as I can tell we basically have the following options:
>
> 1. Never allow people to deploy during the embargo period.
>
> This eliminates the possibility that someone will be helped to gain
> information about the vulnerability by comparing a patched system to an
> unpatched one. However, it means that cloud operators may spend a short
> amount of time "publicly vulnerable" while they reboot their systems. I
> assume it would significantly increase the difficulty of coordinating
> such a deployment, as you would have to reboot *all* your servers in the
> smallest time window possible, instead of being able to stage it over
> several days.
>
> It also increases the temptation for operators to "cheat" by starting
> the process a little bit early. This I think could lead to more
> significant problems community-wise: with incentive to break the rules,
> enforcement becomes an issue -- and I'm sure none of the team want to
> have to deal with that.
>
> 2. Always allow people to deploy during the embargo period.
>
> This is simple on the security team, and minimizes the "publicly
> vulnerable time". It makes deployments easier to coordinate, and avoids
> adding an incentive for "bending" the rules.
>
> However, it does in theory allow an attacker the ability to gain
> information about the vulnerability by comparing patched systems to
> unpatched systems. In practice, the vast majority of the time the
> measurable difference in functionality will be like finding a needle in
> a haystack; and if the attacker had ever even thought to try the
> functionality (e.g., XSA-7), she would have already known about the
> bug. But that may not always be the case.
>
> 3. Have the security team attempt to evaluate the risk.
>
> This adds work to the security team. But it at least allows the
> possibility that, in cases where it's pretty clear that early deployment
> *would* give clear hints to an attacker, they could decide to include
> deployment in the embargo.
>
> 4. Have individual cloud operators evaluate the risk.
>
> This seems like a recipe for disaster.
>
> I think #1 is too risky, particularly from a community perspective. But
> maybe I'm being a bit pessimistic.
>
> In my mind, #3 is basically exactly the same as #2, except that in cases
> where there would clearly be a problem, the team has an option of
> embargoing deployment as well.
>
> I just spent about 10 minutes skimming through the 80 or so XSAs on
> http://xenbits.xen.org/xsa/. In most of the cases, it was pretty clear
> that the only behavior that changed would be behavior which would
> already have clued an attacker into the existence of a potential
> vulnerability. For example, in XSA-108, beforehand some reads from the
> reserved x2apic range would have returned values whereas now they would
> #GP. But if the attacker knew that they returned values, it already
> would have occurred to her to see if they returned anything of interest.
>
> I didn't notice a single exception to this, though admittedly I didn't
> spend much time looking at it.
>
> This suggests to me that #2 is probably not that dangerous the majority
> of the time. It also suggests that there may be a simple criteria that
> can be applied for #3 that can eliminate most of the guesswork: Is
> anything in the original behavior being changed likely to lead an
> attacker to think that there may be a vulnerability there? In the case
> of basically all of them, I think the answer there would be "yes".
>
> So at the moment I would favor #3, then #2; I'm not in favor of #1 but I
> wouldn't strenuously argue against it. But the main thing is that we
> have a clear policy.
I like #3 but as clarified in this paragraph:
> In my mind, #3 is basically exactly the same as #2, except that in cases
> where there would clearly be a problem, the team has an option of
> embargoing deployment as well.
i.e. embargoing deployment is an exceptional case.
Cheers,
James
--
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-29 13:27 ` James Bulpin
@ 2015-01-19 20:36 ` James McKenzie
2015-01-20 8:54 ` Jan Beulich
` (2 more replies)
0 siblings, 3 replies; 52+ messages in thread
From: James McKenzie @ 2015-01-19 20:36 UTC (permalink / raw)
To: xen-devel
On 29/10/14 13:27, James Bulpin wrote:
> George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"):
>> [snip]
>>
>> As far as I can tell we basically have the following options:
>>
>> 1. Never allow people to deploy during the embargo period.
>>
>> 2. Always allow people to deploy during the embargo period.
>>
>> 3. Have the security team attempt to evaluate the risk.
>>
>> 4. Have individual cloud operators evaluate the risk.
>>
>> This seems like a recipe for disaster.
1 and 3 seem like a recipe for disaster as organizations and individual people
who have become aware of issues may have legal and other obligations to their
users, it would also add a fairly strong incentive for a large operator not
to share any issues that they, or a contractor, had found until they had
completed a mitigation.
Perhaps:
5) Have the security team discuss with the discoverer if fixes should be
permitted during the embargo period before the discovery is announced to
the list.
J.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
2 siblings, 0 replies; 52+ messages in thread
From: Jan Beulich @ 2015-01-20 8:54 UTC (permalink / raw)
To: James McKenzie; +Cc: xen-devel
>>> On 19.01.15 at 21:36, <james.mckenzie@bromium.com> wrote:
> On 29/10/14 13:27, James Bulpin wrote:
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process
> post-mortem"):
>>> [snip]
>>>
>>> As far as I can tell we basically have the following options:
>>>
>>> 1. Never allow people to deploy during the embargo period.
>>>
>>> 2. Always allow people to deploy during the embargo period.
>>>
>>> 3. Have the security team attempt to evaluate the risk.
>>>
>>> 4. Have individual cloud operators evaluate the risk.
>>>
>>> This seems like a recipe for disaster.
>
>
> 1 and 3 seem like a recipe for disaster as organizations and individual
> people
> who have become aware of issues may have legal and other obligations to
> their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
>
> Perhaps:
>
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.
Even if this looks like a good idea from an abstract pov, I'm not sure
it's practical: In particular in the case where the security team
determines that by deployment learning about details of the
vulnerability might be possible, but the discoverer insists on allowing
deployment, we'd end up with a rather undesirable situation.
Jan
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
2 siblings, 0 replies; 52+ messages in thread
From: George Dunlap @ 2015-01-20 12:29 UTC (permalink / raw)
To: James McKenzie; +Cc: xen-devel
On Mon, Jan 19, 2015 at 8:36 PM, James McKenzie
<james.mckenzie@bromium.com> wrote:
> On 29/10/14 13:27, James Bulpin wrote:
>>
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process
>> post-mortem"):
>>>
>>> [snip]
>>>
>>> As far as I can tell we basically have the following options:
>>>
>>> 1. Never allow people to deploy during the embargo period.
>>>
>>> 2. Always allow people to deploy during the embargo period.
>>>
>>> 3. Have the security team attempt to evaluate the risk.
>>>
>>> 4. Have individual cloud operators evaluate the risk.
>>>
>>> This seems like a recipe for disaster.
>
>
>
> 1 and 3 seem like a recipe for disaster as organizations and individual
> people
> who have become aware of issues may have legal and other obligations to
> their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
>
> Perhaps:
>
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.
Right -- I think that the general approach is almost always "defer to
the discoverer", specifically to encourage early reporting. Perhaps
it's worth making more explicit somewhere.
-George
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
2 siblings, 0 replies; 52+ messages in thread
From: Lars Kurth @ 2015-02-12 10:44 UTC (permalink / raw)
To: James McKenzie; +Cc: xen-devel
Hi all,
I am assuming this question is in effect resolved. The proposed (and agreed) text basically states that security advisories state whether people will be allowed to deploy. The underlying assumption is that usually this is the case, unless there is a very good reason not to. How the security team handles these does not really need to be codified and could be based on whether the deployment would allow reverse engineering the issue (this would be very rare) and thus put everyone at risk, the discoverer stating that he/she not wanting a deployment, or any other reasons.
Regards
Lars
> On 19 Jan 2015, at 20:36, James McKenzie <james.mckenzie@bromium.com> wrote:
>
> On 29/10/14 13:27, James Bulpin wrote:
>> George Dunlap writes ("Security policy ambiguities - XSA-108 process post-mortem"):
>>> [snip]
>>>
>>> As far as I can tell we basically have the following options:
>>>
>>> 1. Never allow people to deploy during the embargo period.
>>>
>>> 2. Always allow people to deploy during the embargo period.
>>>
>>> 3. Have the security team attempt to evaluate the risk.
>>>
>>> 4. Have individual cloud operators evaluate the risk.
>>>
>>> This seems like a recipe for disaster.
>
>
> 1 and 3 seem like a recipe for disaster as organizations and individual people
> who have become aware of issues may have legal and other obligations to their
> users, it would also add a fairly strong incentive for a large operator not
> to share any issues that they, or a contractor, had found until they had
> completed a mitigation.
>
> Perhaps:
>
> 5) Have the security team discuss with the discoverer if fixes should be
> permitted during the embargo period before the discovery is announced to
> the list.
>
> J.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:55 ` Lars Kurth
2014-10-09 9:37 ` Ian Jackson
@ 2014-11-10 18:01 ` Ian Jackson
2014-11-11 12:39 ` John Haxby
` (2 more replies)
1 sibling, 3 replies; 52+ messages in thread
From: Ian Jackson @ 2014-11-10 18:01 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel
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).
--
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-10 18:01 ` Ian Jackson
@ 2014-11-11 12:39 ` John Haxby
2014-11-12 18:09 ` George Dunlap
2014-11-14 12:10 ` Lars Kurth
2 siblings, 0 replies; 52+ messages in thread
From: John Haxby @ 2014-11-11 12:39 UTC (permalink / raw)
To: xen-devel
On 10/11/14 18:01, Ian Jackson wrote:
> * Domain name(s) which you use to provide Xen software/services.
This makes sense for a services provider but I'm not sure what it means
for a distro. Is this intended to mean a download location for an
installation image and updates? If it's a download location wouldn't
a URL make more sense?
jch
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
2 siblings, 1 reply; 52+ messages in thread
From: George Dunlap @ 2014-11-12 18:09 UTC (permalink / raw)
To: Ian Jackson; +Cc: Lars Kurth, xen-devel
On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> 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 ?
>
> 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
> 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.
+1
> 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
"to prevents" => either "which prevents" or "to prevent"
I take it in general the technical measures you envision is pgp / gpg?
> 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.
+1
>
>
>> 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).
+1
-George
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-12 18:09 ` George Dunlap
@ 2014-11-13 17:36 ` Ian Jackson
0 siblings, 0 replies; 52+ messages in thread
From: Ian Jackson @ 2014-11-13 17:36 UTC (permalink / raw)
To: George Dunlap; +Cc: Lars Kurth, xen-devel
George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > III. Information-sharing
> > ========================
...
> > 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
>
> "to prevents" => either "which prevents" or "to prevent"
Thanks.
> I take it in general the technical measures you envision is pgp / gpg?
No, I don't (honestly) expect anything that sophisticated. I meant
that eg website downloads ought to be password protected. We should
give that as an example.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-10 18:01 ` Ian Jackson
2014-11-11 12:39 ` John Haxby
2014-11-12 18:09 ` George Dunlap
@ 2014-11-14 12:10 ` Lars Kurth
2014-11-14 12:50 ` Ian Jackson
2015-01-16 19:23 ` Ian Jackson
2 siblings, 2 replies; 52+ messages in thread
From: Lars Kurth @ 2014-11-14 12:10 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@chiark.greenend.org.uk> 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@lists.xenproject.org?
>
>
>
> 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
1 sibling, 1 reply; 52+ messages in thread
From: Ian Jackson @ 2014-11-14 12:50 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> 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.
We used to publish CVEs in advance but MITRE asked us to stop doing
so.
We publish the XSA numbers because the purpose of the secrecy is to
prevent vulnerabilities being exploited. The purpose of the secrecy
is not the convenience of the Security Team. Everything that does not
need to be secret for that real purpose should be public.
Keeping secret the existence of an XSA number, and its embargo date,
would not improve the security of systems running Xen. So we should
not do that.
Making the embargo end date public is very useful for people who are
_not_ on the predisclosure list, because it means that they can plan
their response. (And it wouldn't make much sense to publish embargo
end date(s) without XSA numbers.)
> 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.
Another impact of keeping things totally secret in the way you suggest
is that service providers would no longer be able to give honest
reasons for maintenance activity.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-14 12:50 ` Ian Jackson
@ 2014-11-14 17:37 ` Lars Kurth
0 siblings, 0 replies; 52+ messages in thread
From: Lars Kurth @ 2014-11-14 17:37 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
On 14 Nov 2014, at 12:50, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> 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.
>
> We used to publish CVEs in advance but MITRE asked us to stop doing
> so.
>
> We publish the XSA numbers because the purpose of the secrecy is to
> prevent vulnerabilities being exploited. The purpose of the secrecy
> is not the convenience of the Security Team. Everything that does not
> need to be secret for that real purpose should be public.
>
> Keeping secret the existence of an XSA number, and its embargo date,
> would not improve the security of systems running Xen. So we should
> not do that.
>
> Making the embargo end date public is very useful for people who are
> _not_ on the predisclosure list, because it means that they can plan
> their response. (And it wouldn't make much sense to publish embargo
> end date(s) without XSA numbers.)
That is a good explanation and I can live with it.
I was mainly asking, because MITRE asked us to remove CVE numbers and there seemed to be some inconsistency
>
>> 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.
>
> Another impact of keeping things totally secret in the way you suggest
> is that service providers would no longer be able to give honest
> reasons for maintenance activity.
That is also true
Regards
Lars
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-14 12:10 ` Lars Kurth
2014-11-14 12:50 ` Ian Jackson
@ 2015-01-16 19:23 ` Ian Jackson
1 sibling, 0 replies; 52+ messages in thread
From: Ian Jackson @ 2015-01-16 19:23 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On 10 Nov 2014, at 18:01, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
...
> > 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.
I will clarify my proposed wording on this point.
> 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@lists.xenproject.org?
No, the permission will be stated in the advisory. I have reworded
this in my copy of my draft text to make this clearer.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:06 ` Ian Jackson
2014-10-08 23:55 ` Lars Kurth
@ 2014-10-09 11:09 ` George Dunlap
2014-10-10 14:47 ` Jan Beulich
` (2 subsequent siblings)
4 siblings, 0 replies; 52+ messages in thread
From: George Dunlap @ 2014-10-09 11:09 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
On Thu, Oct 9, 2014 at 12:06 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Xen Project Security Team writes ("Security policy ambiguities - XSA-108 process post-mortem"):
>> We welcome any feedback on our decisions and we look forward to
>> clearer directions from the community.
>
> Here is my own, purely personal, response with answers to the
> questions asked. NB that this is not the opinion of Citrix nor of
> the Xen Project Security Team. But I thought I would at least write
> down something concrete for people to argue about.
>
>
>> Sharing amongst predisclosure list members
>
> I think that the answer should be `yes', in principle. There seems
> little point forbidding this.
>
> Allowing greater sharing would perhaps allow problems with patches to
> be discovered (and the revised patches developed) more easily. We
> should provide a clear channel for collaboration between predisclosure
> list members.
>
> Therefore, the policy should be extended by adding, before
> `Organisations who meet the criteria', the new section:
>
> 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.
>
> (That list obviously doesn't exist yet, but if the policy is approved
> we will create it.)
>
> One reason for permitting this is that we want fairness between
> service providers who use their own versions of Xen, and ones who use
> a version from a software provider. Both kinds of service provider
> should be able to test the fix during the embargo.
+1.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:06 ` Ian Jackson
2014-10-08 23:55 ` Lars Kurth
2014-10-09 11:09 ` George Dunlap
@ 2014-10-10 14:47 ` Jan Beulich
2014-10-13 11:23 ` George Dunlap
` (3 more replies)
2014-10-21 12:32 ` Ian Campbell
2014-10-22 23:23 ` Bastian Blank
4 siblings, 4 replies; 52+ messages in thread
From: Jan Beulich @ 2014-10-10 14:47 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
>>> On 09.10.14 at 01:06, <ijackson@chiark.greenend.org.uk> wrote:
>> Sharing amongst predisclosure list members
>
> I think that the answer should be `yes', in principle. There seems
> little point forbidding this.
>
> Allowing greater sharing would perhaps allow problems with patches to
> be discovered (and the revised patches developed) more easily. We
> should provide a clear channel for collaboration between predisclosure
> list members.
I can see the benefits of allowing sharing, but I can also see
downsides: Along with the set of pre-disclosure list members
growing, allowing an increased amount of interchange
(including binaries) increases the risk of a leak. And since
us monitoring what is being exchanged would not be workable
in my opinion, it is also clear that it would be purely incidental
for us (or anyone else) to notice such a leak.
> One reason for permitting this is that we want fairness between
> service providers who use their own versions of Xen, and ones who use
> a version from a software provider. Both kinds of service provider
> should be able to test the fix during the embargo.
I'm not sure about this fairness aspect. Yes, distro consumers can
apply to become a list member on their own (which I personally
dislike, but that's what the community wanted last time round).
But they're then still at the mercy of that distro provider, i.e. by
the time fixed packages get produced and internally tested, the
embargo may be over. In particular this would seem to increase
fairness only between equal size distro providers; smaller ones
may get further disadvantage from that due to their more limited
bandwidth of producing/testing/distributing fixes.
Therefore I would favor only first party consumers to be eligible
to join the list, and no early deployments being permitted at all.
>> 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).
The noise such occasionally (as in the case that triggered this
discussion) may create certainly doesn't help the processing of
an issue "behind the scenes" (i.e. embargoed). Yes, we do
ourselves publish the embargo expiry, but maybe we should
instead reconsider doing so rather than allowing everyone to
widely announce issues (even if indirectly), resulting in all kinds
of speculation?
>> Predisclosure list memembership
This whole final section I completely agree with.
There's one more thing I thought of btw: When we change the
policy following whatever community input we gathered (not just
now, but also in the future), people currently on the pre-disclosure
list may (at least theoretically) end up no longer qualifying for
being on the list. Shouldn't we
- add some kind of statement to the effect of implicit agreement
to changed terms,
- provide means for list members to be removed other than by
them asking for it?
Jan
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-10 14:47 ` Jan Beulich
@ 2014-10-13 11:23 ` George Dunlap
2014-10-13 12:16 ` Lars Kurth
` (2 subsequent siblings)
3 siblings, 0 replies; 52+ messages in thread
From: George Dunlap @ 2014-10-13 11:23 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Ian Jackson
On Fri, Oct 10, 2014 at 3:47 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 09.10.14 at 01:06, <ijackson@chiark.greenend.org.uk> wrote:
>>> Sharing amongst predisclosure list members
>>
>> I think that the answer should be `yes', in principle. There seems
>> little point forbidding this.
>>
>> Allowing greater sharing would perhaps allow problems with patches to
>> be discovered (and the revised patches developed) more easily. We
>> should provide a clear channel for collaboration between predisclosure
>> list members.
>
> I can see the benefits of allowing sharing, but I can also see
> downsides: Along with the set of pre-disclosure list members
> growing, allowing an increased amount of interchange
> (including binaries) increases the risk of a leak. And since
> us monitoring what is being exchanged would not be workable
> in my opinion, it is also clear that it would be purely incidental
> for us (or anyone else) to notice such a leak.
>
>> One reason for permitting this is that we want fairness between
>> service providers who use their own versions of Xen, and ones who use
>> a version from a software provider. Both kinds of service provider
>> should be able to test the fix during the embargo.
>
> I'm not sure about this fairness aspect. Yes, distro consumers can
> apply to become a list member on their own (which I personally
> dislike, but that's what the community wanted last time round).
> But they're then still at the mercy of that distro provider, i.e. by
> the time fixed packages get produced and internally tested, the
> embargo may be over. In particular this would seem to increase
> fairness only between equal size distro providers; smaller ones
> may get further disadvantage from that due to their more limited
> bandwidth of producing/testing/distributing fixes.
On the other hand, small distros can enlist the help of other people
on the list to help produce / test fixes. XenServer has a massive
testing framework that can be used to make sure there aren't any
accidental regressions before they publish a patch; I assume SuSE and
Oracle have something similar. But how much testing bandwidth does
Debian have for security fixes? At the moment CentOS doesn't have an
automated framework: all testing for the XSA-108 update had to happen
by hand. Being able to bring in people on the list using the
xen4centos packages would have been helpful.
-George
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
3 siblings, 1 reply; 52+ messages in thread
From: Lars Kurth @ 2014-10-13 12:16 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Ian Jackson
On 10 Oct 2014, at 16:47, Jan Beulich <jbeulich@suse.com> wrote:
>
>>> Predisclosure list memembership
>
> This whole final section I completely agree with.
>
> There's one more thing I thought of btw: When we change the
> policy following whatever community input we gathered (not just
> now, but also in the future), people currently on the pre-disclosure
> list may (at least theoretically) end up no longer qualifying for
> being on the list. Shouldn't we
> - add some kind of statement to the effect of implicit agreement
> to changed terms,
> - provide means for list members to be removed other than by
> them asking for it?
>
> Jan
I also was wondering whether it would make sense to put a time-limit on applications. For example, we could say that processing an application will take 2 weeks. By doing so, we avoid having to handle applications as a response to media speculation. If we get an application wrong, and allow somebody wrong on the list who then discloses information related to an embargo, we would create risks for others already on the list. This would be the worst possible outcome for the project. Just a thought
Regards
Lars
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-13 12:16 ` Lars Kurth
@ 2014-11-10 17:25 ` Ian Jackson
0 siblings, 0 replies; 52+ messages in thread
From: Ian Jackson @ 2014-11-10 17:25 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel, Jan Beulich
Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> I also was wondering whether it would make sense to put a time-limit
> on applications. For example, we could say that processing an
> application will take 2 weeks. By doing so, we avoid having to
> handle applications as a response to media speculation. If we get an
> application wrong, and allow somebody wrong on the list who then
> discloses information related to an embargo, we would create risks
> for others already on the list. This would be the worst possible
> outcome for the project. Just a thought
I can see that this is attractive, but on the other hand I think it
was very useful to the Xen community as a whole, that members were
able to join /during/ the last furore. I think having an artificial
delay would generate ill-feeling.
Since IMO there should be clear objective criteria, these applications
should be routine, and we shouldn't have too much trouble with them.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-10 14:47 ` Jan Beulich
2014-10-13 11:23 ` George Dunlap
2014-10-13 12:16 ` Lars Kurth
@ 2014-10-29 13:27 ` James Bulpin
2014-11-10 17:21 ` Ian Jackson
3 siblings, 0 replies; 52+ messages in thread
From: James Bulpin @ 2014-10-29 13:27 UTC (permalink / raw)
To: xen-devel
Jan Beulich writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
>
> I can see the benefits of allowing sharing, but I can also see
> downsides: Along with the set of pre-disclosure list members
> growing, allowing an increased amount of interchange
> (including binaries) increases the risk of a leak. And since
> us monitoring what is being exchanged would not be workable
> in my opinion, it is also clear that it would be purely incidental
> for us (or anyone else) to notice such a leak.
It's a risk but I think the benefit of having far fewer vulnerable
systems in production by the time the vulnerability is publically
disclosed outweighs the risk. Today we have a 100% probability that
there will be large numbers of vulnerable systems the day the
embargo is lifted.
> > One reason for permitting this is that we want fairness between
> > service providers who use their own versions of Xen, and ones who use
> > a version from a software provider. Both kinds of service provider
> > should be able to test the fix during the embargo.
>
> I'm not sure about this fairness aspect. Yes, distro consumers can
> apply to become a list member on their own (which I personally
> dislike, but that's what the community wanted last time round).
> But they're then still at the mercy of that distro provider, i.e. by
> the time fixed packages get produced and internally tested, the
> embargo may be over. In particular this would seem to increase
> fairness only between equal size distro providers; smaller ones
> may get further disadvantage from that due to their more limited
> bandwidth of producing/testing/distributing fixes.
>
> Therefore I would favor only first party consumers to be eligible
> to join the list, and no early deployments being permitted at all.
I view fairness here as providing a level playing field for all
concerned. If we do allow sharing then it doesn't mandate that
distros will provide fixes ahead of the embargo being lifted but
allows them to do so if they wish. Each distro can chose its own
policy without artificial constraint.
Cheers,
James
--
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-10 14:47 ` Jan Beulich
` (2 preceding siblings ...)
2014-10-29 13:27 ` James Bulpin
@ 2014-11-10 17:21 ` Ian Jackson
3 siblings, 0 replies; 52+ messages in thread
From: Ian Jackson @ 2014-11-10 17:21 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
Jan Beulich writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> There's one more thing I thought of btw: When we change the
> policy following whatever community input we gathered (not just
> now, but also in the future), people currently on the pre-disclosure
> list may (at least theoretically) end up no longer qualifying for
> being on the list. Shouldn't we
> - add some kind of statement to the effect of implicit agreement
> to changed terms,
> - provide means for list members to be removed other than by
> them asking for it?
Perhaps the right approach is to have a requalification process, where
each member's predisclosure list membership is reviewed periodically.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:06 ` Ian Jackson
` (2 preceding siblings ...)
2014-10-10 14:47 ` Jan Beulich
@ 2014-10-21 12:32 ` Ian Campbell
2014-10-21 14:31 ` Matt Wilson
2014-10-30 11:58 ` Ian Jackson
2014-10-22 23:23 ` Bastian Blank
4 siblings, 2 replies; 52+ messages in thread
From: Ian Campbell @ 2014-10-21 12:32 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
>
> Please provide URLs which are accessible and legible on mobile phone
> browsers, which do not require cookies enabled to load, and which
> are useable with text mode browsers, browsers which do not execute
> Javascript, and with screen readers and other accessibility
> software. If the member of the Xen Project Security Team who
> processes your application finds that their usual web browser does
> not display the required information, when presented with the URLs
> in your email, your application might be delayed or even rejected.
While I appreciate where you are coming from I don't think it is the
place of this policy to rail against the crapitude of the modern web and
try and enforce our own standards on things (much as I would like too).
I don't think it is unreasonable to expect that members of the security
team who typically run a browser with this crud disabled (which includes
myself) would load up their special sandboxed/throwaway browser with a
default config when faced with this sort of thing.
That said, the bits about accessibility seem less unreasonable, on the
basis that its not beyond the realms of possibility that someone
processing an application might not have the option of turning off a
screenreader etc.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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-10-30 11:58 ` Ian Jackson
1 sibling, 2 replies; 52+ messages in thread
From: Matt Wilson @ 2014-10-21 14:31 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Ian Jackson
On Tue, Oct 21, 2014 at 01:32:46PM +0100, Ian Campbell wrote:
> On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
> >
> > Please provide URLs which are accessible and legible on mobile phone
> > browsers, which do not require cookies enabled to load, and which
> > are useable with text mode browsers, browsers which do not execute
> > Javascript, and with screen readers and other accessibility
> > software. If the member of the Xen Project Security Team who
> > processes your application finds that their usual web browser does
> > not display the required information, when presented with the URLs
> > in your email, your application might be delayed or even rejected.
>
> While I appreciate where you are coming from I don't think it is the
> place of this policy to rail against the crapitude of the modern web and
> try and enforce our own standards on things (much as I would like too).
>
> I don't think it is unreasonable to expect that members of the security
> team who typically run a browser with this crud disabled (which includes
> myself) would load up their special sandboxed/throwaway browser with a
> default config when faced with this sort of thing.
>
> That said, the bits about accessibility seem less unreasonable, on the
> basis that its not beyond the realms of possibility that someone
> processing an application might not have the option of turning off a
> screenreader etc.
Due to travel last week for LinuxCon EU and Linux Plumbers Conference
I've not been able to put together a reply to all the points raised a
the start of this thread.
On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.
This process works quite well for the distros email list, where
requests for membership requests are discussion on oss-security (a
public list). Protecting embargoed details should be our primary
concern here, and every time we increase the distribution of this
information we are increasing the risk it will leak. This deserves a
rigorous public debate, not a decision made under fire or undue
pressure.
--msw
[1] http://lists.xenproject.org/archives/html/xen-devel/2012-07/msg00122.html
[2] http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg03085.html
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-21 14:31 ` Matt Wilson
@ 2014-10-21 15:06 ` Jan Beulich
2014-11-10 17:29 ` Ian Jackson
1 sibling, 0 replies; 52+ messages in thread
From: Jan Beulich @ 2014-10-21 15:06 UTC (permalink / raw)
To: Matt Wilson; +Cc: xen-devel, Ian Jackson, Ian Campbell
>>> On 21.10.14 at 16:31, <msw@linux.com> wrote:
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.
And indeed I had intended to bring this point up too, but then forgot.
So - thanks for raising this!
Jan
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
1 sibling, 1 reply; 52+ messages in thread
From: Ian Jackson @ 2014-11-10 17:29 UTC (permalink / raw)
To: Matt Wilson; +Cc: xen-devel, Ian Campbell
Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On this point in particular, back in 2012 [1] I suggested that all
> membership requests should be discussed in public on a community email
> list like xen-devel, or another email list to avoid noise. The Xen
> Project Security Team shouldn't have to evaluate petitions for
> membership while managing an embargoed issue. I brought this up again
> in 2013 [2] regarding the Coverity process.
I agree that publishing applications, and the team's responses, would
be a jolly good idea. I am 100% opposed, though, to any kind of
non-objective `community consensus' process.
Such a system would (a) be unworkable in practice, because no-one
really cares about this kind of tedious makework, and (b) at serious
risk of favouritism (or its opposite).
> This process works quite well for the distros email list, where
> requests for membership requests are discussion on oss-security (a
> public list). [...]
I don't want to criticise another community's process, but I strongly
feel that our arrangements should have broad eligibility based on
objective criteria.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-10 17:29 ` Ian Jackson
@ 2014-11-10 17:39 ` George Dunlap
2014-11-10 18:04 ` Ian Jackson
0 siblings, 1 reply; 52+ messages in thread
From: George Dunlap @ 2014-11-10 17:39 UTC (permalink / raw)
To: Ian Jackson; +Cc: Matt Wilson, Ian Campbell, xen-devel
On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Matt Wilson writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
>> On this point in particular, back in 2012 [1] I suggested that all
>> membership requests should be discussed in public on a community email
>> list like xen-devel, or another email list to avoid noise. The Xen
>> Project Security Team shouldn't have to evaluate petitions for
>> membership while managing an embargoed issue. I brought this up again
>> in 2013 [2] regarding the Coverity process.
>
> I agree that publishing applications, and the team's responses, would
> be a jolly good idea. I am 100% opposed, though, to any kind of
> non-objective `community consensus' process.
>
> Such a system would (a) be unworkable in practice, because no-one
> really cares about this kind of tedious makework, and (b) at serious
> risk of favouritism (or its opposite).
"It's opposite" meaning, "We all hate company X, so let's not let them
join the list"?
>> This process works quite well for the distros email list, where
>> requests for membership requests are discussion on oss-security (a
>> public list). [...]
>
> I don't want to criticise another community's process, but I strongly
> feel that our arrangements should have broad eligibility based on
> objective criteria.
Having black-and-white rules is nice and simple and safe; but in most
reasonably "rich" domains, it's very difficult to come up with simple,
objective criteria that cover all situations satisfactorily. This is
true in morality and law; my guess is that it's true here as well.
But I'd be willing to take a look at such a list; maybe I'm wrong
about how objective we can make things. :-)
-George
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-10 17:39 ` George Dunlap
@ 2014-11-10 18:04 ` Ian Jackson
0 siblings, 0 replies; 52+ messages in thread
From: Ian Jackson @ 2014-11-10 18:04 UTC (permalink / raw)
To: George Dunlap; +Cc: Matt Wilson, Ian Campbell, xen-devel
George Dunlap writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson
> > Such a system would (a) be unworkable in practice, because no-one
> > really cares about this kind of tedious makework, and (b) at serious
> > risk of favouritism (or its opposite).
>
> "It's opposite" meaning, "We all hate company X, so let's not let them
> join the list"?
Yes.
> > I don't want to criticise another community's process, but I strongly
> > feel that our arrangements should have broad eligibility based on
> > objective criteria.
>
> Having black-and-white rules is nice and simple and safe; but in most
> reasonably "rich" domains, it's very difficult to come up with simple,
> objective criteria that cover all situations satisfactorily. This is
> true in morality and law; my guess is that it's true here as well.
>
> But I'd be willing to take a look at such a list; maybe I'm wrong
> about how objective we can make things. :-)
I think the spirit behind our previous criteria is objective. The
problem we had was just that the rules didn't specify enough about the
*form of the predisclosure list application*.
That's why my proposed change doesn't actually touch the criteria part
of the policy. It just formalises the application process.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-21 12:32 ` Ian Campbell
2014-10-21 14:31 ` Matt Wilson
@ 2014-10-30 11:58 ` Ian Jackson
2014-10-31 22:40 ` Matt Wilson
1 sibling, 1 reply; 52+ messages in thread
From: Ian Jackson @ 2014-10-30 11:58 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel
Ian Campbell writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote:
> > Please provide URLs which are accessible and legible on mobile phone
> > browsers, which do not require cookies enabled to load, and which
> > are useable with text mode browsers, browsers which do not execute
> > Javascript, and with screen readers and other accessibility
> > software. If the member of the Xen Project Security Team who
> > processes your application finds that their usual web browser does
> > not display the required information, when presented with the URLs
> > in your email, your application might be delayed or even rejected.
>
> While I appreciate where you are coming from I don't think it is the
> place of this policy to rail against the crapitude of the modern web and
> try and enforce our own standards on things (much as I would like too).
>
> I don't think it is unreasonable to expect that members of the security
> team who typically run a browser with this crud disabled (which includes
> myself) would load up their special sandboxed/throwaway browser with a
> default config when faced with this sort of thing.
I don't think members of the security team should be expected to
either (a) set up a parallel sandboxed web browsing infrastructure,
and keep that sandbox highly available so that it can be used during a
security crisis, or (b) expose themselves to attacks of various kinds.
The security list is very different to most of the situations where I
am currently expecting to use my crud-enabled browser (as you so aptly
put it). At the moment I use my crud-enabled browser when I am
expecting to spend money, or engage with organisations that I already
have a relationship with. That is, where I have already made a
decision to trust the entity whose webshite I'm trying to look at.
I am not personally willing to take random URLs sent to me in email
from strangers and simply visit them in my usual crud-enabled browser
- the same browser I use for my internet banking. I do have a
*sandboxed* crud-enabled browser but it lives at home on a machine
which has restricted access to and from the rest of my network - and I
certainly wouldn't want to try to let it display on my Trusted
Computing Base.
I think that people who want to be on the predisclosure list should
make matters easy for the security team. I think it therefore is only
fair to say that an application might be delayed if the team member
who happens to deal with the application can't conveniently access the
evidence that the applicant is supposed to provide.
And that an application might be rejected entirely if insufficiently
many members of the team are able to access, and hence verify, the
information provided.
Or to put it another way: if the Xen Project community decides to
reject an explicit statement along the lines I propose above, that
won't mean that I will put my own security and privacy at risk when
dealing with predisclosure list applications.
So those applications might be delayed anyway, unless other members of
the team want to take up the slack. Of course if the community
doesn't like my attitude, they're free to get rid of me.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-30 11:58 ` Ian Jackson
@ 2014-10-31 22:40 ` Matt Wilson
2014-11-03 11:37 ` George Dunlap
2014-11-05 11:17 ` Ian Campbell
0 siblings, 2 replies; 52+ messages in thread
From: Matt Wilson @ 2014-10-31 22:40 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel, Ian Campbell
On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:
[...]
> I think that people who want to be on the predisclosure list should
> make matters easy for the security team. I think it therefore is only
> fair to say that an application might be delayed if the team member
> who happens to deal with the application can't conveniently access the
> evidence that the applicant is supposed to provide.
I think that we should reduce any burden on the security team by
making this a community decision that is discussed in public, rather
than something that is handled exclusively in a closed manner as it is
today. This way others who are active community participants can help
with the decision making process can do the investigation and weigh in
on the risk/benefit tradeoff to the security process and the
project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
or [1] if you are willing to visit a URL. ;-)
There's been a bit of talk about "delay" and so on. I'd rather not set
expectations on how long the processing a petition to be added to the
predisclosure list should take. Building community consensus takes
time, just as it does for other activities like getting a patch
applied. I don't think that this process needs to be different.
> And that an application might be rejected entirely if insufficiently
> many members of the team are able to access, and hence verify, the
> information provided.
>
>
> Or to put it another way: if the Xen Project community decides to
> reject an explicit statement along the lines I propose above, that
> won't mean that I will put my own security and privacy at risk when
> dealing with predisclosure list applications.
>
> So those applications might be delayed anyway, unless other members of
> the team want to take up the slack. Of course if the community
> doesn't like my attitude, they're free to get rid of me.
I believe that others would be happy to take up the slack, but they
may not be members of the security team. I'd rather the security team
be able to focus on the matters of preparing fixes and managing
security embargoes, and not have to spend precious time on this aspect
of the policy.
--msw
[1] http://lists.xenproject.org/archives/html/xen-devel/2014-10/threads.html#02532
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
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
1 sibling, 1 reply; 52+ messages in thread
From: George Dunlap @ 2014-11-03 11:37 UTC (permalink / raw)
To: Matt Wilson; +Cc: xen-devel, Ian Jackson, Ian Campbell
On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
> On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:
>
> [...]
>
>> I think that people who want to be on the predisclosure list should
>> make matters easy for the security team. I think it therefore is only
>> fair to say that an application might be delayed if the team member
>> who happens to deal with the application can't conveniently access the
>> evidence that the applicant is supposed to provide.
>
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
>
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for other activities like getting a patch
> applied. I don't think that this process needs to be different.
We might remove some of the (potential) pressure to rush things by
saying that once approved, new members will not receive information
about *currently embargoed* disclosures, but only about *future*
disclosures.
I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
policy) they wouldn't have been eligible to receive XSA-108 anyway.
But perhaps that would be too unpopular to actually implement...
-George
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-03 11:37 ` George Dunlap
@ 2014-11-03 17:23 ` Matt Wilson
0 siblings, 0 replies; 52+ messages in thread
From: Matt Wilson @ 2014-11-03 17:23 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Ian Jackson, Ian Campbell
On Mon, Nov 03, 2014 at 11:37:23AM +0000, George Dunlap wrote:
> On Fri, Oct 31, 2014 at 10:40 PM, Matt Wilson <msw@linux.com> wrote:
[...]
> > There's been a bit of talk about "delay" and so on. I'd rather not set
> > expectations on how long the processing a petition to be added to the
> > predisclosure list should take. Building community consensus takes
> > time, just as it does for other activities like getting a patch
> > applied. I don't think that this process needs to be different.
>
> We might remove some of the (potential) pressure to rush things by
> saying that once approved, new members will not receive information
> about *currently embargoed* disclosures, but only about *future*
> disclosures.
>
> I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
> policy) they wouldn't have been eligible to receive XSA-108 anyway.
>
> But perhaps that would be too unpopular to actually implement...
The decision making mechanics aside, that makes sense to me.
--msw
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-31 22:40 ` Matt Wilson
2014-11-03 11:37 ` George Dunlap
@ 2014-11-05 11:17 ` Ian Campbell
2014-11-06 16:01 ` Lars Kurth
1 sibling, 1 reply; 52+ messages in thread
From: Ian Campbell @ 2014-11-05 11:17 UTC (permalink / raw)
To: Matt Wilson; +Cc: xen-devel, Ian Jackson
On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
>
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for
I think regardless of who is processing the applications what is more
important is to have a concrete set of *objective* criteria. Anyone who
demonstrates that they meet those criteria must be allowed to join.
It reads to me as if you are instead are proposing that the community
apply some sort of subjective standard of risk/benefit tradeoffs and
building consensus about a new membership. I think to take that approach
(whether in public or private) would be against the previous steer from
the community that the list should be fairly widely inclusive -- there
will naturally be a tendency for those already inside the system to be
more conservative about allowing others to join (since it increases
their risk) and so they will tend (not even deliberately) to
overestimate the risk of allowing new memberships.
In the light of the discussions around sharing amongst predisclosure
list members and pre-embargo deployment I think the inclusive nature of
the list is an important balancing factor in the inherent disparity
between distro style consumers and service providers.
If we do not continue take an inclusive approach to the list membership
then my opinion on the matter of sharing and predeploying will be very
different.
> other activities like getting a patch
> applied. I don't think that this process needs to be different.
I don't think this analogy is useful. It is rare that someone who has
had a patch accepted has any incentive to prevent another essentially
unrelated patch from being applied. Also, many of the reasons for not
taking a patch are subjective (coding style, taste, disagreements about
design issues, etc).
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-05 11:17 ` Ian Campbell
@ 2014-11-06 16:01 ` Lars Kurth
2014-11-10 12:35 ` Ian Campbell
0 siblings, 1 reply; 52+ messages in thread
From: Lars Kurth @ 2014-11-06 16:01 UTC (permalink / raw)
To: Ian Campbell; +Cc: Matt Wilson, Ian Jackson, xen-devel
On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
>> I think that we should reduce any burden on the security team by
>> making this a community decision that is discussed in public, rather
>> than something that is handled exclusively in a closed manner as it is
>> today. This way others who are active community participants can help
>> with the decision making process can do the investigation and weigh in
>> on the risk/benefit tradeoff to the security process and the
>> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
>> or [1] if you are willing to visit a URL. ;-)
>>
>> There's been a bit of talk about "delay" and so on. I'd rather not set
>> expectations on how long the processing a petition to be added to the
>> predisclosure list should take. Building community consensus takes
>> time, just as it does for
>
> I think regardless of who is processing the applications what is more
> important is to have a concrete set of *objective* criteria. Anyone who
> demonstrates that they meet those criteria must be allowed to join.
I don't think that having applications discussed and processed on a dedicated public list and objective criteria are mutually exclusive. The two may provide a good balance, and allow for some flexibility in ambiguous cases.
In particular if we either have a strong owner or follow the "two +1 with no -1" model of a set of decision makers who earned that status over time. More or less what we use for access to Coverity Scan output.
Regards
Lars
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-11-06 16:01 ` Lars Kurth
@ 2014-11-10 12:35 ` Ian Campbell
0 siblings, 0 replies; 52+ messages in thread
From: Ian Campbell @ 2014-11-10 12:35 UTC (permalink / raw)
To: Lars Kurth; +Cc: Matt Wilson, Ian Jackson, xen-devel
On Thu, 2014-11-06 at 16:01 +0000, Lars Kurth wrote:
> On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> >> I think that we should reduce any burden on the security team by
> >> making this a community decision that is discussed in public, rather
> >> than something that is handled exclusively in a closed manner as it is
> >> today. This way others who are active community participants can help
> >> with the decision making process can do the investigation and weigh in
> >> on the risk/benefit tradeoff to the security process and the
> >> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> >> or [1] if you are willing to visit a URL. ;-)
> >>
> >> There's been a bit of talk about "delay" and so on. I'd rather not set
> >> expectations on how long the processing a petition to be added to the
> >> predisclosure list should take. Building community consensus takes
> >> time, just as it does for
> >
> > I think regardless of who is processing the applications what is more
> > important is to have a concrete set of *objective* criteria. Anyone who
> > demonstrates that they meet those criteria must be allowed to join.
>
> I don't think that having applications discussed and processed on a
> dedicated public list and objective criteria are mutually exclusive.
I didn't say otherwise. In fact I said the opposite.
My concern was about the criteria being objective and not subjective,
regardless of who is processing them.
Nobody should be doing a "risk/benefit tradeoff to the security process
and the project" when processing an application. They should be going
through a list ticking boxes to show that the applicant has(n't) met
various criteria.
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-08 23:06 ` Ian Jackson
` (3 preceding siblings ...)
2014-10-21 12:32 ` Ian Campbell
@ 2014-10-22 23:23 ` Bastian Blank
2014-10-29 13:27 ` James Bulpin
2014-11-10 17:42 ` Ian Jackson
4 siblings, 2 replies; 52+ messages in thread
From: Bastian Blank @ 2014-10-22 23:23 UTC (permalink / raw)
To: xen-devel
On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote:
> 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.
Why do you think such a hypotetical list needs to be moderated?
> List members who are service providers may deploy fixed versions
> during the embargo, 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.
Why this constraint to "who are service providers"?
> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
> The Security Team has no discretion to accept applications which do
> not provide all of the information required above.
Is there are particular reason why do you want to restrict them?
Bastian
--
You! What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-22 23:23 ` Bastian Blank
@ 2014-10-29 13:27 ` James Bulpin
2014-11-10 17:42 ` Ian Jackson
1 sibling, 0 replies; 52+ messages in thread
From: James Bulpin @ 2014-10-29 13:27 UTC (permalink / raw)
To: xen-devel
Bastian Blank writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> [snip]
> > List members who are service providers may deploy fixed versions
> > during the embargo, 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.
>
> Why this constraint to "who are service providers"?
+1
We already have a definition of eligibility for membership of the
pre-disclosure list and therefore I don't think it is necessary or
desirable to further constrain specific privileges to subsets of the
list members.
Cheers,
James
--
James Bulpin
Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group
Citrix Systems Inc.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Security policy ambiguities - XSA-108 process post-mortem
2014-10-22 23:23 ` Bastian Blank
2014-10-29 13:27 ` James Bulpin
@ 2014-11-10 17:42 ` Ian Jackson
1 sibling, 0 replies; 52+ messages in thread
From: Ian Jackson @ 2014-11-10 17:42 UTC (permalink / raw)
To: Bastian Blank; +Cc: xen-devel
Bastian Blank writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"):
> On Thu, Oct 09, 2014 at 12:06:23AM +0100, Ian Jackson wrote:
> > 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.
>
> Why do you think such a hypotetical list needs to be moderated?
Good question. Primarily because I anticipate two potential failure
modes:
1. People posting non-password-protected URLs, or the like. If the
list is moderated we can notice this quickly and hopefully have
things taken down.
2. Predisclosure list members using the embargoed-information-sharing
forum as a venue for political consensus-building, planning, and
pressurising.
Of these I am most worried about the 2nd.
We have already suffered from a few very dramatic incidents, where
predisclosure list members used their privileged informational
position to try to gain advantage in policymaking and policy
interpretation.
The idea that the predisclosure list members are somehow the most
proper or most real stakeholders and that it is their opinion which
ought to count is distressingly prevalent - especially, it appears,
amongst some of the senior management of some predisclosure list
members. When a security crisis is in full swing, such management
often becomes involved. As I say we have had multiple occasions
where intense political pressure was applied.
It would be a very bad idea to explicitly provide a forum which
predisclosure list members - whose interests are ill-aligned with
those of the public at large - could use for confidential lobbying,
political coordination, and networking. (It might even be illegal;
private collusion by predisclosure list members to manipulate
policymaking might well sometimes be illegal in any case.)
If the list is to be unmoderated, at the very least, we would need an
automatic mechanism which would publish all of the exchanges on a
particular issue at the end of its embargo. ATM we don't have
software to do that.
> > List members who are service providers may deploy fixed versions
> > during the embargo, 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.
>
> Why this constraint to "who are service providers"?
Thanks for pointing out this problem.
This was not intended to be a constraint; it was intended to mean
`_even_ those who are service providers'. Since it was previously
`obvious' that people with private Xen deployments can deploy fixes
when they get them.
I will make a revised proposal for wording in this area.
> > The Security Team should be forbidden from trying to hunt down
> > eligibility information etc. and should instead be mandated to reject
> > incomplete requests.
> > The Security Team has no discretion to accept applications which do
> > not provide all of the information required above.
>
> Is there are particular reason why do you want to restrict them?
As a member of the Security Team I would like to be able to say `sorry
your application did not qualify'. I don't want to have to say `sorry
your application didn't quite meet the criteria and we have chosen not
to exercise our discretion'.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 52+ messages in thread