Re: Security Working Group meeting - Wednesday June 22 - results

[Joseph Reynolds <jrey@linux.ibm.com>]

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

Attendees: Daniil Engranov, Russel Wilson, Yutaka Sugawara, Ruud Haring, 
James Mihm, Joseph Reynolds


1 Agreed to cancel July 6 due to US holiday week


2 CVE management.

Intel’s internal hack-a-thon 3 was held in May 2022.  Working toward 
private disclosure to OpenBMC SRT.

Next steps: James will set up a private meeting with the OpenBMC 
security response team (SRT) to write some privately-disclosed 
vulnerabilities to the private issues database.


3 Measured boot

Measured boot writes firmware images to TPM

There is an effort to enable measured boot for ASPEED AST2600 platforms 
with a TPM attached to the BMC (distinct from host TPM).

Current work: Working toward measured boot  for U-boot.

Pre-requisite work: Openbmc’s ASPEED UBoot was forked and is about 1000 
commits old and will need to be updated because it does not have new 
features needed.


Will need a design for this.  Design to cover:

  *

    Enable the mechanism to push measurements into the TPM.  The design
    may have parts which are specific to AST2600.

  *

    Describe which pieces get measured: SPL(?), U-boot image, kernel
    image, readonly file system.

  *

    Enable network agents (like keylime server, possibly the host
    system) to get measurements from TPM.  Note the measurements are
    digitally signed by the TPM to ensure their integrity.

  *

    Intent to comply with OCP standards.


The design will omit policy questions: Use cases for the attestation 
data, keylime or other servers, policy questions about what to do when 
attestation fails.

Example policy when BMC goes bad (fails attest): BMC is isolated from 
its management network?  From host control?  External agent is notified, 
e.g., datacenter admin, who will then isolate the BMC and schedule it to 
be replaced.


Consider two underlying use cases: BMC management agent is (1) 
network-based or (2) host-based.  The intent to enable use case 1.  Use 
case 2 may be problematic when the policy is to isolate the BMC from its 
host, but nothing in the design is intended to block this use case.


4 Progress on SELinux

Still working on SELinux design (Ruud): implementation work continues to 
help the design.

Implementation progress (Yutaka): Enabled SELinux on AST2600 using Yocto 
Kirkstone version.  BMC boots in selinux permissive mode and basic 
commands work.  The initial readonly flash size increase is 20Mb, (was 
16Mb, now is 16+20Mb = 36Mb total on flash).  Will look into 
configuration changes to reduce the size.

Will need a later/updated version of busybox which has SELinux features 
enabled.

Starting to define policy for basic BMC workloads.

-Joseph

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