Security Working Group meeting - Wednesday July 20 - results

[Joseph Reynolds]

On 7/19/22 10:47 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday July 20 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.

Meeting held 2022-07-20

Attendees: Daniil Engranov, Russel Wilson, Yutaka Sugawara, Ruud Haring, 
James Mihm, Joseph Reynolds, Dhananjay, Jiang Zhang, Krishnan Sugavanam, 
Sandhya Koteshwara


1 CVE Response guidelines

The OpenBMC Security Response Team is meeting regularly to determine 
next steps for how to improve the vulnerability handling process.  See 
background docs here: 
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>

The direction is to move new problems into github advisories as quickly 
as possible.

For example, security vulnerabilities in OpenBMC documentation are 
reported in https://github.com/openbmc/docs/security/advisories 
<https://github.com/openbmc/docs/security/advisories>, BMCWeb defects 
reported in https://github.com/openbmc/bmcweb/security/advisories 
<https://github.com/bmcweb/docs/security/advisories>, etc.  Each repo 
has its own set of security advisories.

The team is working to understand how to give security responders access 
to private security advisories.  Obviously, then we would have to work 
with each repository maintainer to set up its security tab.


2 SELinux updates.

We discussed ideas for the right way to structure the code.  The 
consensus is there are three layers:

Layer 1. Use the existing meta-selinuxbitbake layer.  This layer has the 
poky/meta config changes to use selinux: adds the SELinux support, 
updates coreutils, and introduces policies.

Layer 2: Propose a new bitbake layer, meta-phosphor-selinux, to work on 
top of the meta-selinux layer, to adapt the OpenBMC phosphor 
applications to use SElinux.  This approach avoids changing the base 
repos, so they don’t need to know or care about SELinux.  This further 
customizes openbmc:

 1.

    Override various recipes via *.bbappend to add selinux to recipes
    like busybox, pam, more updates to coreutils, etc.

 2.

    Define minimal/trivial SELinux policies for OpenBMC applications

Layer 3: Add detailed SELinux policy files to the existing meta- layers 
for each target.  For example, add SELinux policies to the OpenPOWER 
platform (the OpenBMC reference platform) 
https://github.com/openbmc/meta-ibm/blob/master/conf/machine/witherspoon.conf

This would do thing like:

 1.

    Increase size of the readonly file system (which is per TARGET).

 2.

    Introduce policy files for that target (test FEATURE to know if
    selinux is enabled).


This three layer approach puts the parts that can be shared into the new 
meta-phosphor-selinux layer, and leaves policy decisions to each TARGET 
machine.


To add SELinux to a machine or a build, the configuration work would be 
here:

 1.

    Insert the meta-selinux layer

 2.

    Insert the meta-phosphor-selinux layer

 3.

    Enhance the layer for your target.



3 TPM/attestation updates.

Working on PoC for the following:

  *

    Working to extend measurements to the TPM

  *

    Working to integrate keylime for remote attestation.


Next steps are to create a design for the step above.  For remote 
attestation: An agent on the BMC collects data.  How can a network 
client get that data?  WIP: Redfish schema for network clients to get 
access to read attestation.  Is there a common solution? We want to 
avoid OEM APIs.


Redfish public discussion here: 
https://redfishforum.com/thread/685/support-bmc-attached-tpm 
<https://redfishforum.com/thread/685/support-bmc-attached-tpm>



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