Security Working Group meeting - Wednesday August 3 - results

Thu Aug 4 05:05:46 AEST 2022

On 8/3/22 7:21 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday August 3 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:
>
> 1. Continue discussing CVE response, SELinux, and Measured Boot
>
> 2. Recommend http header values per email dated 2022-07-22 with 
> subject: BMCWeb support new HTTP headers Referrer-Policy and 
> Feature-Policy renamed to Permissions-Policy
>
> 3. Consider increasing the TLS DH keysize from 1024 to 2048 bits per 
> best practice (reference needed).
>
> 4. Consider migrating this meeting access to Discord > Voice channels 
> >  Security.
>
>
Attended:Joseph Reynolds, Russel Wilson, Yutaka Sugawara, Ruud Haring, 
James Mihm, Dhananjay, Krishnan Sugavanam, Sandhya Koteshwara, James 
Bottomley, Dick from Phoenix, Chris Engel, Gheorge Almas, Alda Ohmacht.

1 Continue discussing CVE response, SELinux, and Measured Boot

DISCUSSION: (We skipped over the first topic and went to the second topic.)

2 Recommend http header values per email dated 2022-07-22 with subject: 
BMCWeb support new HTTP headers Referrer-Policy and Feature-Policy 
renamed to Permissions-Policy.

DISCUSSION:

No discussion.  The email archive is 
https://lore.kernel.org/openbmc/CAH2-KxBuPhrv3bBu3ihr1AW6jpLXWvhr3pY0a4zqdFw0eFKkbw@mail.gmail.com/ 
<https://lore.kernel.org/openbmc/CAH2-KxBuPhrv3bBu3ihr1AW6jpLXWvhr3pY0a4zqdFw0eFKkbw@mail.gmail.com/>

3 Consider increasing the TLS DH session keysize from 1024 to 2048 bits 
per best practice (reference needed).

DISCUSSION:

BMCWeb references the  OWASP guidelines.

Reference: NIST SP 800-131A recommends DH keysize 2048 bits.  This is to 
protect against a supercomputer cracking the session key.

An alternative defense is to disallow the Diffie Hellman (DH) algorithm 
and use Elliptic Curve (ECDH).

Note that removing support for DH will break older browsers which don’t 
support ECDH.    Can we increase keysize?  Yes, will take more of the 
limited BMC compute power.

Two of the places which use SSL: BMCWeb, dropbear SSH.  To change these 
would need a configuration or code change to update the key size.  Note 
the BMC creates other SSL connections which also may need similar 
configuration.  See 
https://github.com/openbmc/docs/blob/master/architecture/interface-overview.md 
<https://github.com/openbmc/docs/blob/master/architecture/interface-overview.md>.

Tangentially-related topic: Use the AST2600 BMC’s Hash and crypto engine 
(HACE) engine?

Kernel patch series for AST2600 crypto engine: 
https://lore.kernel.org/linux-crypto/?q=s%3Ahace 
<https://lore.kernel.org/linux-crypto/?q=s%3Ahace>; note just has HACE 
(AES/SHA), no ACRY yet.  ASpeed is working on Kernel driver for the ACRY 
engine for RSA, etc.

New topic: Enhance OpenBMC to enable compliance with NIST FIPS 
compliance?  IBM and Intel are interested in this.  Add to applicable 
standards 
https://github.com/openbmc/openbmc/wiki/Security-working-group#applicable-standards 
<https://github.com/openbmc/openbmc/wiki/Security-working-group#applicable-standards>.  
Next steps: Articulate what FIPS compliance means, and document how the 
FIPS requirements apply to OpenBMC. Perhaps a design or security doc?

4 Consider migrating this meeting to Discord > Voice channels >  Security.

DISCUSSION:

Three responses were: Why?  Seems okay.  Don’t like Discord.

Access question: Can a web client access the discord voice session?

Also, let’s use the discord #security channel.

The direct link is 
https://discord.com/channels/775381525260664832/1002376534377635860 
<https://discord.com/channels/775381525260664832/1002376534377635860>

We went back to the first topic:

1 Continue discussing CVE response, SELinux, and Measured Boot

DISCUSSION: We only had time for the “CVE Response” subtopic.

Email: Change the OpenBMC project to use github security advisories: 
https://lore.kernel.org/openbmc/f52f9a67-b515-8e4d-f904-6ef73346e599@linux.ibm.com/ 
<https://lore.kernel.org/openbmc/f52f9a67-b515-8e4d-f904-6ef73346e599@linux.ibm.com/>with 
gerrit review here: https://gerrit.openbmc.org/c/openbmc/docs/+/55974 
<https://gerrit.openbmc.org/c/openbmc/docs/+/55974>

New sub-sub-topic: to help with static scanning tools (scanning either 
the firmware image file or scan the source code), there is a desire for 
all OpenBMC repos to have versioning numbers (versus using git 
commitID).  This helps the static source code scan tools report 
version.  Specifically, it helps a security-vulnerability-responder to 
map from a BMC firmware version back to the list of source 
package+version used to create that version.  This is related to the 
software bill of materials (SBOM) concept.

The request for repo maintainers is to periodically increment the 
package version (bitbake PV variable) (either within the recipe or the 
recipe filename) per best practices (need reference).  Examples:

  *

    Uboot has the package version as part of the recipe filename:
    https://github.com/openbmc/openbmc/tree/master/poky/meta/recipes-bsp/u-boot
    <https://github.com/openbmc/openbmc/tree/master/poky/meta/recipes-bsp/u-boot>

  *

    BMCWeb has no branches or tags
    (https://github.com/openbmc/bmcweb/tags
    <https://github.com/openbmc/bmcweb/tags>) and specifies a generic
    package version (PV = "1.0+git${SRCPV}") within its recipe
    (https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/interfaces/bmcweb_git.bb
    <https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/interfaces/bmcweb_git.bb>)
    which merely references the latest bmcweb commit.

James and the security response team to drive this.  Is this a question 
for the Technical Oversight Forum (TOF)?

Next meeting, please cover the Measured boot topic.

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