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

[Nirav Shah]

Hello,

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

I agree i am not proposing a complete transition to session bus. The 
proposal is to move the interactions to and from as you defined it 
"external facing application" and anything that does _*NOT*_ really need 
root access to the session bus by running them as non-root. Applications 
that "may" need root access (may be because the hardware interface 
requires root privilege) will continue to use the system bus for 
communicating with other root application and session bus for 
communication with non root applications.

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

I agree that BMCWeb can run as non root today and still be on the system 
bus. Also agree, this is better than running BMCWeb as root. However, 
"We can then figure out how to further limit the DBus APIs after that" 
is what I want to address. How does having a session bus help solve 
this? This for me is complicated to put down in an email. If my 
explanation below sounds too high level, I would agree with that too.

Essentially today we have 2 possible ways in OpenBMC to implement ACL on 
D-BUS.

1. Using D-Bus configuration file, by default full access is enabled 
(e.g. if a root application crashes a non root application can take over 
the interface while the root application is being restarted). To block 
all possible accesses that could be exploited exception rules need to be 
program. This is what is called discretionary access control. This might 
be fine if we have an exhaustive list of all the possible exploits but 
we rarely do.

2. Using SELinux, apparmor or some sort of a mandatory access control 
system, where unless specifically configured, by default access is 
blocked to everything. In my experience, biggest problem here is a 
separate debug build with special privileges is almost always required. 
This becomes a challenge with on field debug and also when there are 
timing issues. Also, corner conditions where the unit test was not done 
could easily lead to "access denied" failures.

Using a session bus allows for flexible combination of these 2 
approaches with ...

1. By default, blocking "all" non root access to system bus unless 
specifically configured for an interface/method/signal. (MAC approach)

2. By default, allow "all" non root access to the session bus unless 
specifically blocked (DAC approach).

This is the approach I have seen in most of the Linux Distros for 
desktop. I understand OpenBMC does not have the same use cases as 
desktop but in this case it could be lot similar. Does this change your 
mind?

<<<< sdbusplus already has functions to request the system-bus or the 
session-bus (just like sdbus itself does). Some applications 
arecurrently 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.

Thank you for this information.

<<<< Code contributions go through Gerrit.

Understood, thank you!

Thanks,

Nirav.



On 5/2/2022 3:33 PM, Patrick Williams wrote:
> 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.
>
-- 
Nirav Shah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220502/5fefb35a/attachment.htm>