How to handle security vulnerabilities (was: OpenBMC security workgroup status)

How to handle security vulnerabilities (was: OpenBMC security workgroup status)

[Joseph Reynolds]

On 7/11/2018 12:18 AM, openbmc-request@lists.ozlabs.org wrote:
> Message: 1
> Date: Wed, 11 Jul 2018 12:49:36 +0930
> From: Andrew Jeffery <andrew@aj.id.au>
> To: Joseph Reynolds <joseph-reynolds@charter.net>,
> 	openbmc@lists.ozlabs.org
> Cc: James Mihm <james.mihm@intel.com>, bradleyb@fuzziesquirrel.com
> Subject: Re: OpenBMC security workgroup status
> Message-ID:
> 	<1531279176.3103610.1436766272.6E940CAB@webmail.messagingengine.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, 10 Jul 2018, at 11:50, Joseph Reynolds wrote:
>> Here is the OpenBMC security work group status.
>>
>> The OpenBMC security work has been partitioned into four areas:
>> hardware, firmware (Linux, phosphor, etc.), OpenBMC development
>> activity, and downstream development.? Reviews are out for three areas;
>> see https://gerrit.openbmc-project.xyz/#/c/11120/ and 11164.? Work to
>> sketch out firmware security topics is beginning.? We are also beginning
>> to look at topics such as release planning and how to handle security
>> flaws.? For more details, see the group?s agenda and minutes at
>> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI.
> What's the short-term strategy for handling 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 think the first step for the OpenBMC team should be to establish an 
email address (like security@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.  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?

Re: How to handle security vulnerabilities (was: OpenBMC security workgroup status)

[Brad Bishop]

> On Jul 13, 2018, at 2:56 AM, Andrew Jeffery <andrew@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@kernel.org is a private list, so discussions can happen there freely. With respect to informing downstream distros, as mentioned that's done via the linux-distros@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 (like security@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

Re: How to handle security vulnerabilities (was: OpenBMC security workgroup status)

[Andrew Jeffery]

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@kernel.org is a private list, so discussions can happen there freely. With respect to informing downstream distros, as mentioned that's done via the linux-distros@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 (like security@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).

> 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

How to handle security vulnerabilities (was: OpenBMC security workgroup status)

[Joseph Reynolds]

[-- Attachment #1: Type: text/html, Size: 2211 bytes --]