Security Working Group meeting - Wednesday June 8 - results

[Joseph Reynolds]

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 
https://gerrit.openbmc.org/c/openbmc/docs/+/53205 
<https://gerrit.openbmc.org/c/openbmc/docs/+/53205>

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 
https://wiki.yoctoproject.org/wiki/Security).


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.
    https://github.com/openbmc/bmcweb/blob/002d39b4a7a5ed7166e2acad84e0943c3def9492/redfish-core/lib/account_service.hpp#L1941
    <https://github.com/openbmc/bmcweb/blob/002d39b4a7a5ed7166e2acad84e0943c3def9492/redfish-core/lib/account_service.hpp#L1941> 
    This defines:

      o

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

      o

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

      o

        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:
    https://github.com/openbmc/bmcweb/blob/002d39b4a7a5ed7166e2acad84e0943c3def9492/http/routing.hpp#L1236
    <https://github.com/openbmc/bmcweb/blob/002d39b4a7a5ed7166e2acad84e0943c3def9492/http/routing.hpp#L1236>

  *

    We looked at BMCWeb’s implementation of the Redfish privilege
    registry.  Specifically, the generated header file here
    https://github.com/openbmc/bmcweb/blob/master/redfish-core/include/registries/privilege_registry.hpp
    <https://github.com/openbmc/bmcweb/blob/master/redfish-core/include/registries/privilege_registry.hpp>is
    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 
solutions):

  *

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

 1.

    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.

 2.

    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?



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