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

[Xen Project Security Team <security@xxxxxxxxxxxxxx>]

create !
thanks

XSA-108 had a lot of media coverage and generated a lot of interest of
various kinds.  This ended up stress-testing some of our policy and
processes.  During the embargo period the Xen Project Security Team
were faced with some difficult questions of policy interpretation.

Additionally, during the embargo period we had to hastily formalise
our internal tracking arrangements for predisclosure list membership
applications.  We intend to further streamline that system.


A summary of the policy questions, and the answers we gave, is below.
We hope that the community will work towards improving the policy.  As
the Security Team, our role is to implement the policy, not to set it,
so in this message we don't take a position on how the policy should
be clarified.

The Security Team expects that members of the Xen Project community
will respond to this thread (or other threads on this subject) with
everything from discussion of matters of principle to specific wording
proposals.

We welcome any feedback on our decisions and we look forward to
clearer directions from the community.

Thanks,
Xen Project Security Team.


Sharing amongst predisclosure list members
==========================================

The policy says:

  Specifically, prior to the embargo date, pre-disclosure list members
  should not make available, even to their own customers and partners:
   ...
    * patched software (even in binary form) without prior
      consultation with security@xenproject and/or the discoverer.

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.


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.


Service announcements to non-list-member users during embargo
=============================================================

The policy says:

  List members are allowed to make available to their users only the
  following:

    * The existance of an issue
    * The assigned XSA number
    * The planned disclosure date

During the XSA-108 embargo, some service providers wished to make
announcements to their users, for example to notify their users that
their VMs will be rebooted.  The Security Team received enquiries
asking whether that was permitted; observing that some other providers
had read the policy as permitting this and already made such
announcements, we replied saying that we did not object.

The situation should be clarified.


Predisclosure list memembership
===============================

The Xen Project's policy wording on predisclosure list membership was
ambiguous and difficult for the team to work with.  In general when
the rules were ambiguous we tended towards approving applications
which appeared to be from genuine entities, seemed to be applying in
good faith, and who seemed to meet what we saw as the general
principles behind the rules.


Questions which arose include:

Applicants who do not have a public security policy.  The Xen Project
security policy asks for `A link to a web page with your security
policy statement' but doesn't explain what a `security policy
statement' is.  We received a number of applications accompanied by
links to a wide variety of kinds of web pages, including privacy
policies and other documents which do not easily fit into what one
would think of as a `security policy statement'.  Under the
circumstances we ended up mostly waiving this requirement because it
was difficult to pin down the meaning.

Applicants who do not provide a public security reporting address.
This makes it difficult for the Xen Project Security Team to verify
that the people emailing us are properly authorised.  It also invites
entities to benefit from the Xen Project's mature security response
process even when they themselves are so irresponsible as to provide
no way for members of the public to responsibly report security
problems.

Applicants where it is not clear whether they actually use Xen; or, if
Xen is mentioned, where it is unclear how they use it.  The Security
Team spent some time hunting through some applicants' websites and/or
doing websearches to verify whether each applicant actually qualified.
This is not a workable process (especially in crises).

Applicants where the delivery scope of the provided email alias is or
appears to be wider than the policy contemplates.  The Security Team
sometimes made enquiries with applicants about the distribution of
these aliases.  The responses received are of course not verifiable
by the Team.

Verifying the status and eligiblity of applicants was therefore a
difficult and tedious process.  Partly because applicants didn't
always supply the information in the most convenient format; partly
because the information wasn't always on applicants' websites; and
partly simply because some applicants websites were frustratingly
difficult to navigate.


There were three categories of applicant where we felt the policy
required us to reject the application:

Applicants who mentioned proof of concept, experimental or research
Xen setups in support of their application, and did not appear to have
(or be distributing) any Xen deployed in production.

Providers of ancillary software (eg, installers, control panels) who
did not themselves provide modified versions of Xen, but rely on
distro or vendor Xen packages.

Consultants or contractors who may help users configure and manage
systems - although we did tell these that their users might qualify in
their own right.


We hope that the community will set a clearer policy which allows for
straightforward decisionmaking on predisclosure list applications.


-- 

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