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 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. 

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

To run the demo

• As root, copy files dbus_session.service and dbus_session.socket to /etc/systemd/system/
• useradd nirav //or change the .service and .socket file to your user
• systemctl daemon-reload
• systemctl start dbus_session
• ps | grep dbus //will show an additional dbus-broker running
• compile dbus_server.c and dbus_client.c using yocto sdk or write a receipe
• ssh as root, export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/bus1 and ./dbus_server
• ssh as nirav, export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/bus1 and ./dbus_client

With the POC I was able to …..

1. Show dbus_broker_launch “–scope user” works on OpenBMC (A session busses can be created using the right system unit files and launcher provided by D-Bus broker)
1. Since I am new to D-Bus broker and systemd I had to confirm this.
2. Show DBUS_SESSION_BUS_ADDRESS is the only env variable required by root to access the session bus of another user. There is a limitation here, discussed below.

As far as the actual solution, idea would be to have a configuration file to specify which D-Bus interfaces can be on the session bus. An opt in model which does not need any modification to existing and future OpenBMC daemons/applications would be the goal but there are limitations …..

• For root**, to access another user’s session bus, its needs to setuid/setgid to the corresponding user.

• This is because D-Bus actively blocks any user even uid 0 from accessing another’s session bus. It would be a simple patch to make an exception for root. But still something that needs to be maintained.
• My POC was not using sdbus/plus. At the very least, modification will be needed to sdbusplus, sdbus, phosphor-dbus and possibly to object mapper. Not sure if more applications need to change.
• Supporting multiple session D-Buses will be really complicated for a lot of reasons. So even if session bus is a reasonable idea (which I need feedback on), I would not jump into having a session bus per usecase from the get-go.

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

1. Your views on, if this a workable idea?
2. I am hoping I can isolate all the changes to sdbusplus, sdbus, phosphor-dbus and object mapper. What else might need to change?
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?

Thanks,

Nirav.