Security Working Group meeting - Wednesday November 10 - results

Joseph Reynolds jrey at linux.ibm.com
Thu Nov 11 07:35:24 AEDT 2021


On 11/10/21 8:38 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday November 10 at 10:00am PDT.
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:
>

Attended: Joseph, Bruce, Vernon, James, Caci, Jiang, Dick, Ratan, Dhananjay


Agenda items discussed:

1 Next meeting Nov 24 “Thanksgiving eve”

Votes: cancel, cancel, cancel.  Agreed.  Someone else schedule a meeting?


2 Should OpenBMC become a CVE Numbering Authority (CNA).

Ref: https://www.cve.org/ResourcesSupport/AllResources/CNARules 
<https://www.cve.org/ResourcesSupport/AllResources/CNARules>

This would better integrate the CVE process with github.

OpenBMC looked into become a CNA years ago.  See the old review: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/15621 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/15621>

Is it worthwhile for openBMC to become a CNA?  Yes, we have had multiple 
CVEs per year and believe this will continue.  We have filled out the 
form (at cve.mitre.org) to create CVEs and have become familiar with 
writing CVE language.

We agreed to pursue becoming a CNA.  No objections.  James will follow up.


3 Make progress on these competing reviews:

https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/48564 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/48564>

https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/48633 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/48633>

Ensure we have a CI test for this.  TODO: Joseph to contact George on email.


4 The OpenBMC security response team (SRT) is working toward improving 
the way it handles private security vulnerabilities before they are 
disclosed.  (See notes from previous meetings.)

The repo https://github.com/openbmc/openbmc/security-response 
<https://github.com/openbmc/openbmc/security-response>was created for 
this, the idea is to make this private to the SRT members and  use  
https://github.com/openbmc/openbmc/security-response/issues to identify 
issues and track progress.

Open questions: What content should this repo have?

How to add content? Do  we  need  files?  Any private content? Web 
interfaces vs gerrit vs command line (git submissions?)

The README should have content like:

  *

    the purpose of the repo (to track security vulnerability issues for
    the overall openbmc organization before public disclosure).

  *

    the fact that the repo is private and access is controlled by the
    github @security-response team.

  *

    Link to
    https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team-guidelines.md
    <https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team-guidelines.md>

  *

    Instructions to use
    github.com/openbmc/openbmc/security-response/issues for new issues

Nothing in the README needs to be private.  The content which must 
remain private is in the issues.

Code reviews for fixes would use their own repo, and perhaps private 
gerrit review process, as stated in the 
obmc-security-response-team-guidelines.md.


The question for github is: What should a security response team (like 
https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md 
<https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md>) 
use to track private security reports before public disclosure?


The overall structure might be like this:

  *

    github.com/openbmc/openbmc/issues -- currently stores security
    advisories: search for “advisory”

  *

    github.com/openbmc/openbmc/security/advisories -- proposed place for
    all advisories; this is what github wants us to use.

  *

    github.com/openbmc/openbmc/security-response -- new PRIVATE repo for
    the SRT to track new security vulnerabilities toward closure


See

https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization 
<https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization>


Next steps:

  *

    Add github.com/openbmc/openbmc/security-response README -- see above
    for ideas

  *

    Create first low-sev issue in
    https://github.com/openbmc/openbmc/security-response/issues
    <https://github.com/openbmc/openbmc/security-response/issues>and
    ensure it is not accidentally disclosed via a Discord bot, an email
    bot, or any other way.



>
>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph



More information about the openbmc mailing list