How to handle security vulnerabilities

[Joseph Reynolds]

On 7/16/2018 5:19 AM, openbmc-request at lists.ozlabs.org wrote:
> Message: 1
> Date: Sun, 15 Jul 2018 22:11:18 -0400
> From: Brad Bishop<bradleyb at fuzziesquirrel.com>
> To: Andrew Jeffery<andrew at aj.id.au>
> Cc:openbmc at lists.ozlabs.org
> Subject: Re: How to handle security vulnerabilities (was: OpenBMC
> 	security workgroup status)
> Message-ID:<AC6EEF0D-8D17-4936-A6DD-4059CB459EBC at fuzziesquirrel.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>> On Jul 13, 2018, at 2:56 AM, Andrew Jeffery<andrew at aj.id.au>  wrote:
>>
>> On Fri, 13 Jul 2018, at 07:49, Joseph Reynolds wrote:
>>>> What's the short-term strategy for handling [security] vulnerability
>>>> reports received in the gap between now and getting some formal
>>>> process in place?
>>> We don't have a strategy.  Let's discuss it here.
>>>
>>> Officially (https://github.com/openbmc/openbmc/  section "Bug Reporting")
>>> issues are managed on GitHub.
>>>
>>> Unofficially, Brad volunteered to accept one batch of security
>>> vulnerability reports and distribute them, presumably to the OpenBMC TSC
>>> members (https://github.com/openbmc/docs  section "Technical Steering
>>> Committee ") or their delegates.  I assume they would privately contact
>>> a trusted OpenBMC contributor who could address the problem.
>>>
>>> We could adapt the Linux model
>>> (https://www.kernel.org/doc/html/v4.16/admin-guide/security-bugs.html),
>>> although I am still looking for information on what the Linux security
>>> team does with the bug report.  For example, how security group members
>>> track and discuss problems among themselves, how they pull in additional
>>> resources to fix or mitigate the problem, and how they inform downstream
>>> distros before announcing the problem, etc.
>> I thought the documention described most of this?security at kernel.org  is a private list, so discussions can happen there freely. With respect to informing downstream distros, as mentioned that's done via thelinux-distros at vs.openwall.org  list. As for how they pull in additional resources to fix or mitigate the problem, that's going to depend on the affected parties. No-one can order anyone to fix a particular problem, but the developers/maintainers/vendors involved have skin in the game so should be motivated to fix the issue.
>>
>>> I think the first step for the OpenBMC team is to establish an email
>>> address (likesecurity at openbmc.org), subscribe only trusted people to
>>> that email list, and update the docs to explain that you should email
>>> the security team for security questions, and use issues for everything
>>> else.
>> Sounds good to me. Who can sort out security@? Brad? I'm sure we could sort out list hosting on ozlabs.org if necessary (like we use for this list).
> Unless someone replies in the negative in the next couple days, lets just
> do another list on ozlabs.org, if ozlabs.org is ok with that:-)
>
>>> Presumably, the security team would communicate privately among
>>> themselves and the submitter to assess the situation, and contact
>>> OpenBMC community members privately to address the problem.
>>> This would be an easy step to take, and would move the team in the right
>>> direction.  What do you think?
>> Sounds good enough for the moment!
>>
>> Andrew
The description of the OpenBMC security vulnerability reporting program 
we agreed to during the community call is now in review: 
https://gerrit.openbmc-project.xyz/#/c/11511, so please review it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180716/190d8c53/attachment.html>