Security Working Group - Wednesday November 25 - results

[Joseph Reynolds]

On 11/24/20 4:53 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday November 25 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. Phosphor user manager - default group roles

Richard and Joseph went through the email thread and agreed on the 
solution for the ssh group.  This includes the use case where SSH is 
enabled, but only special pre-created users are allowed to access it 
(such as manufacturing and service accounts).


We also discussed an image feature to disable SSH.  Is there such an 
image feature in yocto/OpenEmbedded?  If so, use it; otherwise add an 
option to openbmc.  Specifically, if SSH is not present, then remove the 
“ssh” group privilege from the image (such as phosphor-user-manager).


We discussed the concept of “image type” as an image feature.  A 
“development” image would have features such as SSH enabled and is 
intended for developers.  A “production” image would have fewer (or 
different) features enabled and is intended for production servers.  
This might simplify testing.  However, we did not discuss any specific 
features (beyond SSH).


Joseph mentioned that changing the SSH default was one of several 
desired changes...


Joseph is moving forward with a proof of concept (PoC) for a special 
pre-created “service” account that has a custom OEM “ServiceAgent” role 
that has the custom “PerformService” privilege.  I believe all agreed 
that this privilege is needed to perform operations such as change a 
permanent MAC address or a FRU serial number.


(Joseph introduced the way we plan to authenticate the special-privilege 
pre-created users.  Having a default password is problematic.  The 
service user (person) will create a certificate pair, and work with the 
BMC admin to install the “public” copy onto the BMC.  Details pending.)


(Joseph mentioned the “service” account is “special” in several ways: 
special authentication as mentioned above, and there are no APIs to 
delete or modify the account.  The main idea is to prevent the admin 
user from escalating into the special account.)


We discussed if the OEM ServiceAgent role would be (A) a superset of the 
Administrator role, or (B) if it should be a subset of Administrator 
privileges plus the custom PerformService privilege.  Option A is the 
use case currently needed.  Option B may be more difficult to design, 
implement, document, test, and reason about.


We discussed the idea of making all these changes in BMCWeb and 
user-manager, and which would become image features.

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