Re: [Xen-devel] [PATCH RFC] Make all public hosting providers eligible for the pre-disclosure list

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-11-15 at 17:14 +0000, George Dunlap wrote:
> As discussed on the xen-devel mailing list, allow any public hosting
> provider to join the pre-disclosure list:

Thanks for doing this.

> * Change "Large hosting providers" to "Public hosting providers"
> * Add rule of thumb for what "public hosting provider" means
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.
> 
> NOTE: This RFC is meant to be a way to start a discussion on the exact
> wording which will be voted on.  Once it has gone through review from
> the xen-devel mailing list, I will post an "RC" and announce it on the
> Xen blog, as well as on xen-users.  Once discussion seems to have
> converged, I will post a "FINAL" one, which I will put up for a vote.
> 
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> ---
>  security_vulnerability_process.html |   27 ++++++++++++++++++++-------
>  1 file changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/security_vulnerability_process.html 
> b/security_vulnerability_process.html
> index e305371..35236c9 100644
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -194,16 +194,18 @@ if(ns4)_d.write("<scr"+"ipt type=text/javascript 
> src=/globals/mmenuns4.js><\/scr
>      addresses (ideally, role addresses) of the security response teams for
>      significant Xen operators and distributors.</p>
>      <p>This includes:<ul>
> -      <li>Large-scale hosting providers;</li>
> +      <li>Public hosting providers;</li>
>        <li>Large-scale organisational users of Xen;</li>
>        <li>Vendors of widely-deployed Xen-based systems;</li>
>        <li>Distributors of widely-deployed operating systems with Xen 
> support.</li>
>      </ul></p>
>      <p>This includes both corporations and community institutions.</p>    
> -    <p>Here as a rule of thumb "large scale" and "widely deployed" means an
> -    installed base of 300,000 or more Xen guests; other well-established
> -    organisations with a mature security response process will be considered 
> on
> -    a case-by-case basis.</p>    
> +    <p>Here as a rule of thumb, "public hosting provider" means
> +    "selling virtualization services to the general public";
> +    "large-scale" and "widely deployed" means an installed base of
> +    300,000 or more Xen guests.  Other well-established organisations
> +    with a mature security response process will be considered on a
> +    case-by-case basis.</p>

I agree with Ian that relaxing this for software vendors also seems the
correct thing to do.

>      <p>The list of entities on the pre-disclosure list is public. (Just the 
> list
>      of projects and organisations, not the actual email addresses.)</p>  
>      <p>If there is an embargo, the pre-disclosure list will receive
> @@ -229,8 +231,19 @@ if(ns4)_d.write("<scr"+"ipt type=text/javascript 
> src=/globals/mmenuns4.js><\/scr
>         <li>The planned disclosure date</li>
>      </ul></p>
>  
> -    <p>Organisations who meet the criteria should contact security@xen if 
> they wish to receive pre-disclosure of advisories. Organisations should not 
> request subscription via the mailing list web interface, any such 
> subscription requests will be rejected and ignored.</p>
> -    <p>Normally we would prefer that a role address be used for each 
> organisation, rather than one or more individual's direct email address. This 
> helps to ensure that changes of personnel do not end up effectively dropping 
> an organisation from the list</p>
> +    <p>Organisations who meet the criteria should contact security@xen
> +      if they wish to receive pre-disclosure of advisories.  Please
> +      include in the e-mail: <ul>
> +     <li>The name of your organization</li>
> +     <li>A brief description of why you fit the criteria</li>
> +     <li>A security alias e-mail address (see below)</li>
> +     <li>A web page with your security policy statement</li>
> +     <li>If you are a public hosting provider, a web page with your public 
> rates</li>

For the last two "a link to ...". Seems obvious but some people are very
literal ;-)

I think it would be good to also include something like:
                <li>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 to regarding
                confidentiality during an embargo period</li>

Or something like that.

I wonder if we shouldn't also include under the list of "pre-disclosure
list members should not make available," include "Failure to adhere to
this will be grounds for removal from the list".

I suppose then we need an appeals process though. How about
"Reinstatement will require a post to the xen-devel mailing list
explaining the procedures which have been put in place to prevent any
further breach of confidentiality" + a three strikes rule (any org who
managed so mess this up three times isn't likely to stay in business
long enough to require an appeals process against that ;-)).

Also, and I understand this is most likely taking things way too far, I
was wondering about requiring the request to be signed by a key which
itself has a signature from a key in the "strong
set" (http://pgp.cs.uu.nl/plot/) of PGP keys (implemented by me being
able to find a path from my key to it). This is just another hurdle
which serves to ensure that list members are in some sense legitimate.
(NB I'm not sure I buy this argument, surely there are corrupt types in
the strong set). This hurdle might be too big in practice? It doesn't
seem so to me but then I hang around with a lot of Debian types ;-)

What are we going to do for existing members? Ask them to requalify by
some deadline? I wouldn't normally bother but the statement about
agreeing to the confidentiality terms (if we do that) seems like a
worthwhile thing to require?

> +      </ul>
> +      Organisations should not request subscription via the mailing
> +      list web interface, any such subscription requests will be
> +      rejected and ignored.</p>
> +    <p>We prefer that a role address be used for each organisation, rather 
> than one or more individual's direct email address. This helps to ensure that 
> changes of personnel do not end up effectively dropping an organisation from 
> the list</p>

Ack on /prefer/require/ suggestion.

>  
>      
>      <h3>Organizations on the pre-disclosure list:</h3>



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