Security Working Group meeting - Wednesday June 8

Security Working Group meeting - Wednesday June 8

[Joseph Reynolds]

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:

1. No topics.




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

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

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

[Joseph Reynolds]

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@linux.ibm.com>
To: 	openbmc <openbmc@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

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

[Ed Tanous]

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