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

[Ed Tanous]

On Mon, May 2, 2022 at 2:58 PM Nirav Shah <nirav.j2.shah at linux.intel.com> wrote:
>
> Hello,
>
>
>
> I am new to OpenBMC (and BMC ),

Welcome!  Glad to have you.

> 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.
>
> The biggest challenge is the use of system bus and non root access to the system bus.

This statement could be phrased a little more precisely.  The biggest
challenge is that:
1. bmcweb (and all user-facing daemons) run as root.
2. There is no way to define an ACL such that a user-facing daemon
would not have access to something.
4. User-facing daemons enforce their own authorization systems,
instead of relying on something out of process, which makes them more
vulnerable than is ideal.

> As previously suggested an ACL based approach can work. (whether it is using a D-Bus ACL configuration file or SELinux)
> 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

I think the thing you haven't touched on here is that in the way linux
generally uses these, session busses are spun up per-user session,
which provides some level of abstraction and segmentation between
various users.  it'd be interesting to talk through that as an
architecture, and how it maps, but as Patrick points out elsewhere,
simply moving nearly everything onto a shared session bus doesn't
really do much to solve the security concerns.

An architecture that would be interesting would be:

1. On creation of a session, bmcweb registers the session with linux,
and gives the session that users permissions levels, similar to how a
"normal distro" session manager would act.
2. ACLs would define specifically (at dbus level) what that user was
allowed to do.  Ideally we could drive some of these from
PrivilegeRegistry.
3. When user requests come in, bmcweb would route the requests to the
appropriate session bus for that user.

And in theory, at the end, we could remove the permissions code from
bmcweb, because we'd be relying on linux permissions, which are
arguably better.

>
> 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 …..
>
> 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)
>
> Since I am new to D-Bus broker and systemd I had to confirm this.
>
> 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.

This is something that would need to be looked at in more depth technically.

>
> 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.
>
> Your views on, if this a workable idea?

I have very similar concerns with Patrick;  With that said, if these
are minor additions to existing daemons that are optional, I'd be in
support of some amount of experimentation in this regard to find an
acceptable solution, but I don't think the above gets us to what we
need.

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

I'm fairly certain every daemon needs some changes to define the
appropriate ACLs.  Essentially we need to distribute BMCWEBs privilege
registry mapping to dbus, so individual daemons can put in ACLs that
define whether their APIs are Admin, Operator, user, or read-only
privilege level.

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

Keep in mind, bmcweb also accesses things that:
1. Aren't openbmc dbus daemons (primarily systemd)
2. Supports accessing data through unix sockets (KVM, serial port,
virtual media, ect).
3. Supports accessing system data through the filesystem (EventLog,
HostLog, ect).
4. Has data that it needs to persist (sessions, guids, ect) in
bmcweb_persistent_data.json.

If you want to run bmcweb as non-root on any non-trivial system, you'd
have to find solutions for those use cases as well.  WIth that said,
if you want to focus on the dbus aspects first, happy to work through
that piecemeal, but it will mean that we will have to support both
configs (bmcweb as root, and bmcweb as non-root) for some amount of
time, so keep that in mind when you write your patches.

>
>
>
> Thanks,
>
> Nirav.
>
>
>
>
>
>
>
> --
> Nirav Shah