* Re: Security Working Group - Wednesday April 14 - results
2021-04-13 22:08 Security Working Group - Wednesday April 14 Joseph Reynolds
@ 2021-04-15 15:49 ` Joseph Reynolds
0 siblings, 0 replies; 2+ messages in thread
From: Joseph Reynolds @ 2021-04-15 15:49 UTC (permalink / raw)
To: openbmc
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
>
^ permalink raw reply [flat|nested] 2+ messages in thread