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

Fri May 13 02:11:23 AEST 2022

On 5/9/22 3:08 PM, Ed Tanous wrote:
> 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.

In the 2022-05-11 Security Working Group meeting, I advocated that we 
document a model for how some of the BMC's network-facing services use 
D-Bus interfaces.
The model would be organized by interface, similar to 
https://github.com/openbmc/docs/blob/master/security/network-security-considerations.md 
so it could be incrorporated into a larger threat model.
The model should be adequate to show, for example, how bmcweb and the 
ipmi (ipmitool) network-facing services invoke D-Bus APIs to perform 
user management functions, and how access should be limited to admin users.

This model could be used, for example, to help describe that only bmcweb 
and ipmi should have access to user-management APIs.  Or it could be 
used to help describe the user authority needed to invoke each of the 
user-management APIs.  Or whatever authorization mechanism the projects 
decides to have.

Joseph

Ref:
Security Working Group meeting: 
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
>
>> 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