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

[Patrick Williams]

On Mon, May 02, 2022 at 11:00:01PM -0700, Nirav Shah wrote:
> 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.

To be honest, this sounds even more complex than just using the session
bus for almost everything.

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

Not really. :)  Yes, "too high level" is probably the simplest statement
here.

Let me switch this discussion around a bit.  Please name me 4 daemons,
which currently reside on the system bus, and that bmcweb does not and
should not ever access.  

I think you'll find it hard to enumerate because our architecture is
purposefully very flat.  I know the codebase fairly well and have thought
about it for a bit and can only come up with one: kcsbridge (or btbridge).
Perhaps you could expand to a few of the systemd daemons (org.freedesktop)
where we've created an abstraction (xyz.openbmc_project), but I actually see
present day code in bmcweb which interacts with the ones I was thinking of
there.

So, effectively everything would need to be moved to the session bus
_and_ we'd still need a mechanism for bmcweb to access some of the
system bus end-points (via restricted ACLs), but effectively that is
still every single dbus endpoint.  This proposed move didn't actually
accomplish anything from a security standpoint in practice.

-- 
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/20220503/4333fd63/attachment.sig>