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

[Ed Tanous <edtanous@google.com>]

On Tue, May 3, 2022 at 12:49 PM Bills, Jason M
<jason.m.bills@linux.intel.com> wrote:
>
>
>
> On 5/3/2022 6:02 AM, Patrick Williams wrote:
> > 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.
> One possible example that maybe isn't in place yet is MCTP.  If we end
> up exposing an MCTP interface over D-Bus, is there risk that this could
> be used maliciously since a compromised application running as root has
> direct access to the MCTP interface?
>
> If the direct MCTP interface is on the system bus and the filtered MCTP
> interface is on the session bus, then a compromised non-root application
> would still be blocked from accessing the direct MCTP interface.
>

+1 IPMB would be similar to this, although I suspect that we really
don't want to put raw MCTP on dbus like we did with IPMB.  Arguably
even in the IPMB case there were likely better paths, and now that the
shared IPMB state is in the kernel, needing to pass arbitrary ipmb
messages over dbus is probably not something we'd do if we did it
again.

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