Security Working Group - Wednesday August 21 - results

[Joseph Reynolds]

On 8/19/19 1:58 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday August 21 at 10:00am PDT.
>
> Current topics:
> - Development work:
>  + expired password design
>  + phosphor-audit design
> - Recent discussion of CVEs that apply to OpenBMC

Meeting held 2019-08-21:


Note: The 2019-09-04 meeting is cancelled. Next meeting: 2019-09-18.  
See notes for details.



1.

Current development items:

- Expired password design: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/23849 and email -- 
joseph discussed - no comments

- Auditing user actions: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/23870 -- no comments

- Prevent overlay filesystem corruption: 
https://lists.ozlabs.org/pipermail/openbmc/2019-August/017704.html -- 
general agreement that filesystem overlays are problematic, and we 
should move to a model where we don’t need overlays, and just mount 
read-write file systems as needed.

- Nancy mentioned they are reviewing security features related to the 
Nuvaton BMC boot ROM and boot block.


2.

There was a question about flashing the firmware (host, and similarly BMC).

- The current OpenBMC firmware update is described here: 
https://github.com/openbmc/docs/blob/master/code-update/code-update.md

- There is interest in using Redfish support for this.(Use the email 
list to follow up.)


3.

We discussed “verified boot” and “One Time Programmable” (OTP) memory to 
hold secret keys needed to establish a root of trust.We talked about 
Aspeed’s AST2500 and AST2600 support for this.  Designs are coming soon!


4.

Joseph: Review level of effort in handling CVEs 
(https://lists.ozlabs.org/pipermail/openbmc/2019-August/017578.html).

- Dick mentioned how this works in the UEFI project...following 
responsible disclosure guidelines:

   + We can freely discuss CVEs, issues, and fixes when fixes are available.

   + However, if someone asks about a CVE or an issue for which we don’t 
have a fix, ideally we would not respond to the problem, not even to say 
that we were invoking the OpenBMC security response team 
(https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md).Then 
followup with the response team.

- Dick mentioned that the information embargo period for security fixes 
is 6 months.This gives time for the fixes to be built, tested, deployed, 
and activated.

- TODO: Joseph will propose similar guidelines for the response team.


5.

Joseph: Added web security wish list items (under 
https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list).There 
were no comments.


6.

We elected to cancel the Sep 4 meeting and meet again on Sep 18 because 
of the Open Source Firmware Conference (OSFC ~ https://osfc.io/).


7.

Joseph gave highlights from attending the Blackhat conference 
(https://www.blackhat.com/us-19/) related to firmware security.He plans 
to send an email with details.


- Joseph

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