[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem
Xen Project Security Team writes ("Security policy ambiguities - XSA-108 process post-mortem"): > [snip] > > It is (still!) ambiguous whether predisclosure list members may share > fixes and other information with other predisclosure list members. We > intended to fix this ambiguity following the XSA-7 discussion but > the policy was never updated. > > During the XSA-108 embargo the Security Team were asked whether this > permitted; we concluded that since we had said `yes' last time, and > documented this in the XSA-7 postmortem, and the community had failed > to change the policy, we should probably say `yes' again. > > The community should formally correct this ambiguity. I would like to see it explicitly permitted for predisclosure list members to share source and binary fixes along with impact and mitigation information with each other. The latter is important as a Xen distributor may wish to interpret the raw information in terms more meaningful to that distributor's users (for example if the distributor's product hides PV/HVM/etc virt mode behind templates then that distributor may wish to inform its users which templates are impacted rather than the more raw form of (e.g.) "PV guests"). > [snip] > > Deployment on public systems of fixed versions during embargo > ============================================================= > > It is ambiguous whether the wording above prohibits deployment by a > service provider of patched hosting software running customer VMs. > Some predisclosure list members thought that this was prohibited; > others thought that it was permitted and accordingly deployed the > XSA-108 fix during the embargo. > > This question should be resolved, clearly, one way or the other. I would like to see it explicitly permitted for _any_ predisclosure list member to deploy a fix on production systems before the embargo is lifted. However there should be an "exception" mechanism for the (hopefully uncommon) case that such a deployment would create an unacceptably high probability of the details of the vulnerability being discoverable. This exception mechanism would be used based on the judgement of the Security Team with post-mortems used to provide feedback on this decision making if necessary. Cheers, James -- James Bulpin Sr. Director, Technology, XenServer/Networking, Cloud & Service Provider Group Citrix Systems Inc. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |