Security Working Group - Wednesday April 14 - results

[Joseph Reynolds]

On 4/13/21 5:08 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday April 14 at 10:00am PDT.
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>, 
> and anything else that comes up:
>
> 1. (no topics)
>
> It should be a lively discussion.

The discussion was less lively and more cerebral.

We continued (or restarted) the “physical interface” discussion from  
2021-03-17.

Why focus on BMC interfaces?  Shouldn’t we focus on threats?

  *

    Agreed we should focus on threats.  But the threats come from the
    BMCs interfaces, so we need a clear model of the BMC interfaces
    first to help organize and talk about threats.

  *

    Many organizations have tried threat modeling, and they all say to
    start with modeling the architecture of the thing you want to
    protect.  For OpenBMC, that’s the BMC.

  *

    The high level security schemes used by OpenBMC contributors (see
    https://github.com/openbmc/openbmc/wiki/Security-working-group
    <https://github.com/openbmc/openbmc/wiki/Security-working-group>)
    all say the same thing:

      o

        Create a threat model

      o

        Describe the interfaces as the first part of the threat model


Should we focus on the BMC or focus on the overall system?

Spoiler alert: The focus is on the BMC itself.


This is a tricky issue.  Discussion:

The BMC is a component in its host and the BMC operates various host 
components outside of itself.  This makes it hard to understand the 
BMC’s security boundary.  Both the BMC and the overall host system need 
to be protected.


The trust model for using BMCs in computer servers (OpenBMC’s initial 
model) is:

  *

    The BMC does not trust its host system.

  *

    The host system (for example, the host hypervisor) does not trust
    its BMC.

  *

    Various host elements effectively trust everyone, that is, they take
    no steps to protect themselves.  They may be operated by either BMC
    or host.  (See examples below.)


Expect the host system to protect itself from the BMC.  How it does so 
is outside the scope of the OpenBMC project.  It is expected that host 
security experts will review the shared host-BMC access to host 
components and their complex interactions as carefully as the BMC 
security experts.


In summary, the BMC’s threat model’s focus is on protecting itself.  
When the BMC is integrated into a host system, the BMC’s threat model is 
integrated into the host system’s threat model.


Scope of the BMC architectural model:

The model needs to be sufficient to show allBMC interfaces.  This 
includes host components outside the BMC which the BMC interacts with.  
A rule of thumb: if the OpenBMC project has code to interact with 
something, the BMC’s architectural model should have a place for that 
something.


The model begins with physical architecture: the physical BMC device (as 
a card or board builtin), continues with its physical interfaces to its 
host, and physical host elements the BMC connects with (as outlined 
below).  [This is intended to be descriptive and should not be 
interpreted to exclude virtual BMCs like QEMU].


Examples of items in scope:

  *

    All inband and all host-BMC interfaces.

  *

    All out of band interfaces.

  *

    All management interfaces (such as IPMI and Redfish).

  *

    All physical presence interfaces (like power buttons, physical USB
    ports, and intrusion detection switches).


The model then builds layer by layer.  For example, each layer needed to 
describe:

  *

    PLDM over MCTP over {LPC, PCIe, UART}

  *

    Virtual media is USB over IP over {the BMC’s network}


Some of these items are merely used by OpenBMC and are not very 
interesting.  (Example: i2c).  The BMC’s threat model will likely not 
say much about them, but they need to be present in the architectural 
description.


Each item ought to be described separately so a system integrator who 
mix&match protocols (example: MCTP over PCIe -vs- MCTP over LPC) can 
cleanly refer to the items they need.


Examples of physical elements shared between BMC & host:

  *

    Physical USB ports (BMC-attached and host-attached)

  *

    Physical network port (NC-SI)

  *

    Access to host processors

  *

    Access to cooling fans

  *

    Watchdog timers(?)


Additional examples of complex BMC / host interactions:

  *

    BMC handling host firmware.  The BMC provides firmware to the host,
    and the host may validate its firmware before using it, such as via
    digital signatures.

  *

    Virtual media aka USB over IP

  *

    BMC control of host BIOS settings.  For example, BMC can disable
    host USB ports.

  *

    BMC access to host serial, typically host console



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