[ovs-dev] [PATCH] Update SECURITY.md

[Ben Pfaff]

Thanks.

Some background:

I don't want to say "there will be a response within 24 hours" because
I do like to take off weekends, and because I might easily judge
something as not important even though it was sent to the security
list.  But I also don't want to say "there will be a response within
72 hours" because that makes it sound like we're a bunch of lazy
so-and-sos, which we're not.  That's why I left it so vague
originally.

There's also likely to be an extra delay if anyone sends me encrypted
email, because my private key is only on one computer that I usually
leave at home.

On Thu, Jan 08, 2015 at 09:17:30PM +0000, Andrew Kampjes wrote:
> I change back to a more general statement, given that we can't really
> guarantee a response time.
> 
> On Fri Jan 09 2015 at 09:54:03 Ben Pfaff <blp at nicira.com> wrote:
> 
> > I don't know what to say for response time.  In general I expect it to
> > be pretty fast for anything that is clearly urgent.
> >
> > On Fri, Jan 09, 2015 at 09:48:11AM +1300, Andrew Kampjes wrote:
> > > Both good points, thanks Flavio.
> > > Ben, can you confirm what the expectation for response should be?
> > >
> > > Will swap those paragraphs too.
> > >
> > > On 9 January 2015 at 05:11, Flavio Leitner <fbl at redhat.com> wrote:
> > >
> > > > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote:
> > > > > Include more specific GPG recomendation usage.
> > > > > Add generalised rules for vulnerabilties.
> > > > >
> > > > > Signed-off-by: Andrew Kampjes <a.kampjes at gmail.com>
> > > > > ---
> > > > >  SECURITY.md | 41 +++++++++++++++++++++++++++++------------
> > > > >  1 file changed, 29 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/SECURITY.md b/SECURITY.md
> > > > > index d558d44..c85e594 100644
> > > > > --- a/SECURITY.md
> > > > > +++ b/SECURITY.md
> > > > > @@ -23,25 +23,33 @@ What is a vulnerability?
> > > > >  ------------------------
> > > > >
> > > > >  All vulnerabilities are bugs, but not every bug is a vulnerability.
> > > > > +Vulnerabilites compromise one or more of:
> > > > > +
> > > > > +    * Confidentiality (Personal and company data/secrets).
> > > > > +    * Integrity (trustworthyness and correctness).
> > > > > +    * Availability (Uptime and service).
> > > > > +
> > > > >  Here are some examples of vulnerabilities to which one would expect
> > to
> > > > >  apply this process:
> > > > >
> > > > > -    * A crafted packet that causes a kernel or userspace crash.
> > > > > +    * A crafted packet that causes a kernel or userspace crash
> > > > > +      (Availability).
> > > > >
> > > > >      * A flow translation bug that misforwards traffic in a way
> > likely
> > > > > -      to hop over security boundaries.
> > > > > +      to hop over security boundaries (Integrity).
> > > > >
> > > > >      * An OpenFlow protocol bug that allows a controller to read
> > > > > -      arbitrary files from the file system.
> > > > > +      arbitrary files from the file system (Confidentiality).
> > > > >
> > > > >      * Misuse of the OpenSSL library that allows bypassing
> > certificate
> > > > > -      checks.
> > > > > +      checks (Integrity).
> > > > >
> > > > >      * A bug (memory corruption, overflow, ...) that allows one to
> > > > >        modify the behaviour of OVS through external configuration
> > > > > -      interfaces such as OVSDB.
> > > > > +      interfaces such as OVSDB (Integrity).
> > > > >
> > > > > -    * Privileged information is exposed to unprivileged users.
> > > > > +    * Privileged information is exposed to unprivileged users
> > > > > +      (Confidentiality).
> > > > >
> > > > >  If in doubt, please do use the vulnerability management process.  At
> > > > >  worst, the response will be to report the bug through the usual
> > > > > @@ -53,8 +61,17 @@ Step 1: Reception
> > > > >
> > > > >  To report an Open vSwitch vulnerability, send an email to the
> > > > >  ovs-security mailing list (see "Contact" at the end of this
> > document).
> > > > > -A security team member should reply to the reporter acknowledging
> > that
> > > > > -the report has been received.
> > > > > +A security team member should reply to the reporter within 24 hours
> > > > > +acknowledging that the report has been received.
> > > >
> > > > There is no on-call team as far as know.  Perhaps Ben can confirm that.
> > > > So issues reported during holidays or weekends may take more than
> > > > 24 hours to get a reply.  My concern here is that it will create a non
> > > > practical expectation.
> > > >
> > > > Perhaps something like this:
> > > > A security team member should reply to the reporter within 24 hours
> > > > on business days acknowledging that the report has been received.
> > > >
> > > > > +Reporters may ask for a GPG key while initiating contact with the
> > > > > +security team to deliver more sensitive reports.
> > > > > +If the reporter has used GPG while disclosing, further vulnerability
> > > > > +details should also be discussed using GPG.
> > > > > +
> > > > > +Please don't report security vulnerabilities to the ovs-dev list,
> > > > > +ovs-bug list or github issues to allow the team ovs security team
> > > > > +to responsibly fix the vulnerability.
> > > >
> > > > It looks more clear/effective to me if we swap the two
> > > > paragraphs.  I mean, first tell to not report on ovs-dev and
> > > > then talk about GPG details...
> > > >
> > > > fbl
> > > >
> > > > >  Please consider reporting the information mentioned in
> > > > >  REPORTING-BUGS.md, where relevant.
> > > > > @@ -132,11 +149,11 @@ vSwitch user who is interested and can be
> > > > considered trustworthy
> > > > >  enough could be included.  To become a downstream stakeholder, email
> > > > >  the ovs-security mailing list.
> > > > >
> > > > > -If the vulnerability is public, skip this step.
> > > > > +If the vulnerability is already public, skip this step.
> > > > >
> > > > >
> > > > > -Step 5: Full Disclosure
> > > > > ------------------------
> > > > > +Step 5: Public Disclosure
> > > > > +-------------------------
> > > > >
> > > > >  When the embargo expires, push the (reviewed) patches to appropriate
> > > > >  branches, post the patches to the ovs-dev mailing list (noting that
> > > > > @@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a
> > > > security team member
> > > > >  with a key that is in a public web of trust.
> > > > >
> > > > >
> > > > > -Contact
> > > > > +Contact
> > > > >  =======
> > > > >
> > > > >  Report security vulnerabilities to the ovs-security mailing list:
> > > > >
> > > >
> > > >
> > > _______________________________________________
> > > dev mailing list
> > > dev at openvswitch.org
> > > http://openvswitch.org/mailman/listinfo/dev
> >