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

[Ed Tanous]

On Wed, Jun 8, 2022 at 12:18 PM Joseph Reynolds <jrey at linux.ibm.com> wrote:
>
> 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.
>
> Joseph
>
>
> -------- 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
> 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
>

ACK.  Considering how many people in the security working group seem
to care about this stuff, it would help a lot if they could
participate in reviews.  Even some of the files mentioned above
(privilege registry specifically) have changed recently to try to
improve this situation, but received very little feedback input on
Gerrit, which is unfortunate given the amount of discussion I see
going on above.

I support (at least in part) most of the experiments suggested above,
and can't wait to see what the patchsets and designs look like so we
can talk in the next level of detail.

-Ed