Security Working Group meeting - Wednesday February 3

Security Working Group meeting - Wednesday February 3

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday February 3 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. Continue to discuss APIs to disable HTTPS 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006>

2. Review Linux-PAM changes 
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/40102 
<https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/40102> and 
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-user-manager/+/39853 
<https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-user-manager/+/39853> 


3. Discuss plans for IBM Enterprise system “service” login support.
3a. Implement restricted roles and restricted privileges per Redfish 
spec DSP0266 1.12.0 aka 2020.4 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.12.0.pdf 
<https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.12.0.pdf> 

3b. Story here: https://github.com/ibm-openbmc/dev/issues/1756 
<https://github.com/ibm-openbmc/dev/issues/1756>
3c. Need a special REST API to require variable privileges: 
https://github.com/ibm-openbmc/dev/issues/2875 
<https://github.com/ibm-openbmc/dev/issues/2875>

4. Need help for 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39756 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39756> ?

5. (Discord > OpenBMC > #yocto 2021-02-02) Security concerns using a 
sstate cache.


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>

Re: Security Working Group meeting - Wednesday February 3 - results

[Joseph Reynolds]

On 2/2/21 10:51 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday February 3 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. Continue to discuss APIs to disable HTTPS 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006 
> <https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006>

Is there a use case to allow users to disable the interface they are 
currently using?  For example, a Redfish user might disable IPMI and 
SSH, but why would they disable HTTPS?

Agreed: Redfish should not be allowed to disable HTTPS.  IPMI should not 
be allowed to disable IPMI in a way that it could not be used to 
re-enable itself.

We also mentioned MCTP channels.


What {does|should} happen to login sessions {ipmi|https} when an 
interface is disabled?  They get logged off.  The ports get “cut” and 
the services get disabled.

We discussed a race condition such that HTTPS disables IPMI at the same 
time IPMI disabled HTTPS.  Both might become disabled, resulting in no 
usable interfaces.  The consensus was this problem is not worth solving 
at this time.

>
> 2. Review Linux-PAM changes 
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/40102 
> <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/40102> and 
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-user-manager/+/39853 
> <https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-user-manager/+/39853> 
>

Joseph described the effort to replace deprecated and removed PAM 
modules.  These modules were used by OpenBMC and their configuration 
arguments were modified by Redfish APIs (details are in the reviews).


>
> 3. Discuss plans for IBM Enterprise system “service” login support.
> 3a. Implement restricted roles and restricted privileges per Redfish 
> spec DSP0266 1.12.0 aka 2020.4 
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.12.0.pdf 
> <https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.12.0.pdf> 
>
> 3b. Story here: https://github.com/ibm-openbmc/dev/issues/1756 
> <https://github.com/ibm-openbmc/dev/issues/1756>
> 3c. Need a special REST API to require variable privileges: 
> https://github.com/ibm-openbmc/dev/issues/2875 
> <https://github.com/ibm-openbmc/dev/issues/2875>

Joseph introduced the Redfish spec changes (DSP0266 referenced above).

We talked about aspects of the Access Control File (ACF) design

The ACF design is similar to mutual TLS (mTLS) which is already 
implemented in OpenBMC.  Can we build on top of the mTLS design?

What are the similarities between IBM’s & Intel’s approach?


>
> 4. Need help for 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39756 
> <https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39756> ?
Need reviews.

>
> 5. (Discord > OpenBMC > #yocto 2021-02-02) Security concerns using a 
> sstate cache.

[Copied from Joseph’s Discord post]: I think yocto security agrees that 
you should trust a shared sstate cache that someone else built only if 
you trust that other party. (Reference 
email:https://lists.yoctoproject.org/g/yocto-security/message/264 
<https://lists.yoctoproject.org/g/yocto-security/message/264>). For 
someone to use the OpenBMC project-level sstate cache, they would have 
to trust whoever has write access to that cache (such as: the host 
system, the host system admin, and the CI build process -- in other 
words, the geissonator). With this outlook, it seems okay to me to have 
a shared sstate cache.

DISCUSSION: General agreement that this is okay, with the understanding 
that individual companies may decline to use this cache.

Bonus topic 6:


6 There is interest in using yocto reproducible builds 
<https://wiki.yoctoproject.org/wiki/Reproducible_Builds>- 
https://wiki.yoctoproject.org/wiki/Reproducible_Builds

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