Security Working Group - Wednesday January 20 - results

[Joseph Reynolds]

On 1/19/21 11:56 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday January 20 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. (email) Call for OpenBMC 2.9.0 release.

Reviewed the security wiki item for this.


>
> 2. Yocto email: Dropped openssl support for deprecated algorithms,
>    including TLS 1.0 and TLS 1.1.  I (Joseph) believe we already have
>    dropped TLS below TLSv1.2, but let’s take a look to see if we want
>    any changes in this area.

dropped for HTTPS, not necessarily for SSH.  Related discussion:

Move away from dropbear SSH to OpenSSH?  Why?  See the new issue 
https://github.com/openbmc/openbmc/issues/3756 
<https://github.com/openbmc/openbmc/issues/3756>.  The group had general 
agreement to do this.


>
> 3. (gerrit review): Does anyone have a use case to allow customers to
>    disable HTTPS?
>    https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006
> <https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39006>

Yes, we have use cases to disable the BMC’s HTTPS interface.  For 
example, a BMC controlled via the KCS interface (although these BMCs 
typically have their HTTPS interface removed entirely).

For the gerrit review: Allow HTTPS to be disabled, but don’t make it 
easy for the admin to remove their only access to the BMC (bricking).

The BMC’s service configuration manager 
(xyz.openbmc_project.Control.Service.Attributes at 
/xyz/openbmc_project/control/service/) shall issue an error message like 
“Cannot disable the %1{HTTPS,IPMI,etc} interface from a request via that 
same interface because that might brick the BMC.  Make the request from 
some other interface.”


An alternative to the above, we discussed having a behavior like “You 
cannot disable the last remaining interface”.


We discussed enhancing the BMC’s service configuration manager with a 
built-time option to disable the ability of the BMC admin from enabling 
and disabling the BMC’s interfaces.  For example, have a build-time 
block list (CANNOT_CHANGE_RUNNING_ATTRIBUTE_OF_THE_FOLLOWING_SERVICES) = 
“HTTPS” so any attempt to enable or disable HTTPS will be blocked and 
fail with a nice message like, “You cannot change the running state of 
the %1{HTTPS} service.”  In this way, the person who configures the BMC 
image can ensure that certain services are always running.


We discussed what happens to existing SSH sessions when SSH interface is 
disabled?

What happens to existing Redfish sessions when HTTPS interface is disabled?

What happens to existing IPMI LAN+ when IPMI/RMCP+ interface is 
disabled?  (RMCP.  No current use case to disable the KCS IPMI 
interface.  Compare with KCS restricted mode.)


>
> 4. (gerrit review): Linux-PAM dropped support for pam_cracklib and
>    pam_tally2.  These are being removed from OpenBMC usage because they
>    are no longer available from yocto, but the function is not yet
>    replaced.  See https://github.com/openbmc/openbmc/issues/3750
>    <https://github.com/openbmc/openbmc/issues/3750>.

This work is happening now.  Reviews appreciated. ADDED BONUS ITEMS:

5 The Intel security is planning to focus on penetration testing (an 
internal hackathon).


6 Update on Linux process isolation.

Still working on solutions for common cases.

Difficulties: file permissions, testing other people's code, wrong 
architecture need to be upgraded

Hard to take the first step because you’ll need dbus permissions working 
which is difficult.

Example: difficulties when the (downstream) nbd launches another process.

Idea: Have a new image feature to enable process isolation.  Grow over 
time to encompass additional BMC services.
>
> 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>