Fwd: Security Working Group meeting - Wednesday June 8 - BMCWeb authority checks

Joseph Reynolds jrey at linux.ibm.com
Thu Jun 9 05:18:41 AEST 2022

BMCWeb maintainers,

FYI, the security working group reviewed BMCWeb's basic authority 
checking mechanisms, and I have summarized that discussion in the 
meeting notes.  We are struggling to find ways to improve or tighten the 
D-Bus API layer.

This email is for information only.  No action is needed.


-------- Forwarded Message --------
Subject: 	Re: Security Working Group meeting - Wednesday June 8 - results
Date: 	Wed, 8 Jun 2022 14:06:37 -0500
From: 	Joseph Reynolds <jrey at linux.ibm.com>
To: 	openbmc <openbmc at lists.ozlabs.org>

On 6/7/22 11:12 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday June 8 at 10:00am PDT.
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:

Attended: Joseph Reynolds, Yutaka, Ruud Haring, Dick from Phoenix, 
Krishnan Sugavanam, Mark McCawley, Russel Wilson

The meeting went about 20 minutes over time (80 minutes total).

1 Progress on SELinux gerrit review 

Note the design is intended for BMC which have a larger flash image 
size.  For example the OpenBMC witherspoon reference platform has a 64Mb 
flash divided into 2 sides, with space for a 20Mb readonly filesystem, 
so it is too small.  SELinux is intended for BMC with 256Mb SPI flash, 
where SELinux adds  about  20Mb (initial guess).

Ruud is continuing to work on the design.  Discovering what config 
changes are needed by enabling SElinux.  For example, SELinux adds a 
`-Z` flag to many commands to show SELinux attributes. SELinux-enabled 
busybox (-Z flag) exists.  Attempting to build from Yocto recipe.

Attempting to follow meta-selinux docs.  Debugging.  Reach out with 
questions to the yocto community (perhaps via email list in 

We did a deep dive on BMCWeb authority checking by following a Redfish 
API call:


After a Redfish session is created, that session has a role and a
set of privileges.


When that session is used to invoke an HTTP operation, that
operation’s  privileges are checked against the session’s privileges.


The Redfish spec described this in DSP0266 > Security details >
Authorization.  We peeked at this spec.


We looked at the Redfish “delete user” API as implemented by BMCWeb.

This defines:


the HTTP operation (DELETE
/redfish/v1/AccountService/Accounts/<str> where <str> is a


along with the privileges required to perform that operation:
namely redfish::privileges::deleteManagerAccount, which only
Administrator users have.


The C++ code to implement the operation (which basically invoke
the phosphor-user-manager API via D-Bus system bus with parameters


Bus: xyz.openbmc_project.User.Manager


Object path: (as C++ variable userPath)


Interface: xyz.openbmc_project.Object.Delete


Method: Delete


We talked about, but did not look at BMCWeb’s router function, which
routes operations to their implementation (such as “delete user”
above), and we talked about but did not look at the authority check
it performs.  That code is in the “handle” method, here:


We looked at BMCWeb’s implementation of the Redfish privilege
registry.  Specifically, the generated header file here
a translation of the redfish spec’s privilege registry.  The BMCWeb
contributors maintain this file (runs as needed and checked in to
the repo), and the definitions are used within the operations
handlers (such as “delete user”).

A basic understanding is that OpenBMC’s authority checking (which asks: 
“am I allowed to perform this operation?”) is handled by BMCWeb, and 
there is no authority checking at the D-Bus layer. (Currently anyone who 
needs to use a D-Bus API must have root authority). This is a security 
problem we are trying to solve. (TODO: articulate why this is a problem.)

Two approaches were briefly discussed (not necessarily as complete 


BMCWeb drops to the logged-in user (switch user command (su) or the
setuid kernel call).


SELinux labeling model.

For example, if desired, we can use SELinux to ensure the “delete user” 
dbus api can only be used by bmcweb and that it cannot be used by any 
other service (like IPMI or by SSH/bash).  Then we can ensure only the 
phosphor-user-manager service is allowed to modify the /etc/passwd & 
shadow files.  Doing so will lock down who is allowed to perform BMC 
user management.

Revisit some initial use cases for selinux (examples):


Limit what files bmcweb process can reach.  In my opinion (Joseph)
this would be an easy initial use case for SELinux because BMCWeb
only touches a small set of files,and has no reason to touch other
files.  Also phosphor-user-manager only touches a small set of files
(including /etc/shadow), and has no reason to touch other files or
to reach out to the network.


Control which D-Bus apis bmcweb is allowed to use. (All of them?)

Here is an attempt to state a security problem more clearly: How do we 
limit specific dbus calls to specific users or to specific processes?  
Alternatively: How do we push down the BMCWeb’s authority model into the 
D-Bus APIs?  And what additional security would this give us?


> 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

More information about the openbmc mailing list