Running OpenBMC Daemons/Applications as non root using D-Bus Session/User Bus.

[Patrick Williams]

On Mon, May 02, 2022 at 02:55:39PM -0700, Nirav Shah wrote:
> Hello,
> 
> I am new to OpenBMC (and BMC ), so apologies if I am posting this in the 
> wrong place. I have been looking at this 
> <https://github.com/openbmc/openbmc/issues/3383> issue.Here is my 
> summary of the problem statement, please do comment and let me know if I 
> got this right.
> 
>  1. The biggest challenge is the use of system bus and non root access
>     to the system bus.
>  2. As previously suggested an ACL based approach can work. (whether it
>     is using a D-Bus ACL configuration file or SELinux)
>  3. However, it does require an exact configuration to cover all
>     security scenarios (for MAC) and IMO “may” make debugging efforts
>     harder.

I don't really think the issue is session bus vs system bus.  There
isn't really a significant difference between the two.  Just moving
everything to a session bus doesn't solve any security concerns.

> Coming from a desktop background (which additionally uses D-BUS 
> session/user bus for user isolation), I was investigating if having a 
> session bus would help. For OpenBMC, the idea would be to allow non root 
> application to communicate with each other and with root** applications 
> on a single session bus to begin with. This can be further augmented 
> using ACL based approaches if needed. I have a small POC, which tests 
> this on OpenBMC with D-Bus broker

What does moving everything to a session bus improve from a security
perspective?  I can't think of much.

I think the primary concern is that external-facing applications, like
IPMI and Redfish:

    1. Are the biggest attack vector for being compromised.
    2. Once compromised could do anything they wanted on the system,
       including on the DBus.

Moving everything from the system to session doesn't really improve
either of these aspects.

From an ACL perspective there is similarly a large surface area of dbus
interfaces that these (especially Redfish) need in order to do their
primary job.  The ACLs likely need to be written at an method/property
level within the DBus interfaces and this is, frankly, a lot of work.  I
suspect the 'best' answer is to put decorators into the
phosphor-dbus-interface YAML to be able to generate the appropriate
ACL configs.


> I am happy to start with a design document on git hub and also make some 
> code changes, but I had a few questions.

Code contributions go through Gerrit.

>  1. Your views on, if this a workable idea?

If you try to move all openbmc applications to the session bus, most of
them will work just fine.  A few of them will need secondary access to
the system bus because they operate on upstream components
(org.freedesktop interfaces) that only live on the system bus.  Anything
that initiates systemd service operations would certainly be affected.

>  2. I am hoping I can isolate all the changes to sdbusplus, sdbus,
>     phosphor-dbus and object mapper. What else might need to change?

sdbusplus already has functions to request the system-bus or the
session-bus (just like sdbus itself does).  Some applications are
currently written explicitly requesting the system-bus and some are
written requesting the 'default' bus, which is system for root and
session for non-root.  I was mentioning elsewhere recently that this
inconsistency is a poor situation for unit-testing as it is.

>  3. If I can make all these changes, I was thinking of starting with
>     BMCWeb as non root but since BMCWeb interfaces with a lot of daemons
>     that would be a big step. Any better ideas?

If the only goal is to run bmcweb as non-root, this could probably be
achieved without any change at a DBus level.  Use the systemd magic to
run the bmcweb service as a non-root user and add an ACL so that user can
access everything on system DBus.  This at least limits the bmcweb
process from accessing kernel APIs and limit the surface area to just
the available DBus interfaces.  We can then figure out how to further
limit the DBus APIs after that.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220502/9c5db5ce/attachment.sig>