Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel