Re: Security policy ambiguities - XSA-108 process post-mortem

[Tim Deegan <tim@xen.org>]

At 13:27 +0000 on 29 Oct (1414585666), James Bulpin wrote:
> Xen Project Security Team writes ("Security policy ambiguities - XSA-108 process post-mortem"):
> > [snip]
> >
> > It is (still!) ambiguous whether predisclosure list members may share
> > fixes and other information with other predisclosure list members.  We
> > intended to fix this ambiguity following the XSA-7 discussion but
> > the policy was never updated.
> > 
> > During the XSA-108 embargo the Security Team were asked whether this
> > permitted; we concluded that since we had said `yes' last time, and
> > documented this in the XSA-7 postmortem, and the community had failed
> > to change the policy, we should probably say `yes' again.
> > 
> > The community should formally correct this ambiguity.
> 
> I would like to see it explicitly permitted for predisclosure list members
> to share source and binary fixes along with impact and mitigation
> information with each other. The latter is important as a Xen distributor
> may wish to interpret the raw information in terms more meaningful to
> that distributor's users (for example if the distributor's product hides
> PV/HVM/etc virt mode behind templates then that distributor may wish to
> inform its users which templates are impacted rather than the more raw
> form of (e.g.) "PV guests").
> 
> > [snip]
> > 
> > Deployment on public systems of fixed versions during embargo
> > =============================================================
> > 
> > It is ambiguous whether the wording above prohibits deployment by a
> > service provider of patched hosting software running customer VMs.
> > Some predisclosure list members thought that this was prohibited;
> > others thought that it was permitted and accordingly deployed the
> > XSA-108 fix during the embargo.
> > 
> > This question should be resolved, clearly, one way or the other.
> 
> I would like to see it explicitly permitted for _any_ predisclosure
> list member to deploy a fix on production systems before the embargo
> is lifted.

I reluctantly agree.

The original purpose (IIRC) of the predisclosure list was to allow
development and testing of fixes to happen in advance of disclosure.
Adding large service providers to the list increased fairness: they
are likely to have modified or wholly custom-built Xen distributions
requiring their own dev & test work, and so would be at a disadvantage
when the vulnerability was disclosed.  Allowing them to _deploy_ in
advance, however, gives them an advantage over non-members -- their
systems are demonstrably more secure.

However, I think that given the community's decision to widen the
predisclosure list as much as it has (so that it now covers basically
any service provider), that advantage goes away.  In which case we
should allow deployment on the grounds that it means fewer unpatched
systems when the embargo expires.

There is a slippery-slope argument here that having such a large list
means that details will inevitably leak, and we might as well save
ourselves all this effort and disclose immediately, but I don't really
believe it. :)  All I'll say for that is that we should be very clear
about the expectation that predisclosure periods will be _short_.

Cheers,

Tim.