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

Andrew Kampjes a.kampjes at gmail.com
Thu Jan 8 20:48:11 UTC 2015


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:
> >
>
>



More information about the dev mailing list