Re: BMC redundancy

[Andrew Jeffery <andrew@aj.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

On Fri, 2018-02-02 at 13:10 -0800, Vernon Mauery wrote:
> On 02-Feb-2018 11:18 AM, Andrew Jeffery wrote:
> > Hi Deepak,
> > 
> > > So several of the existing OpenBMC apps implement specific D-Bus
> > > services. What does it take to make remote D-Bus calls to such apps?
> > > - It doesn't look like the D-Bus spec or libdbus officially has anything
> > > for D-Bus across computers. There are some good notes at
> > > https://www.freedesktop.org/wiki/Software/DBusRemote/.
> > 
> > Applications can cannect to remote dbus servers; the --address
> > option to dbus-daemon allows it to listen on a TCP socket and
> > setting DBUS_SESSION_BUS_ADDRESS will point applications in the
> > right direction. So there are probably two ways we could do this:
> 
> Putting DBus on an externally-available TCP socket is a security 
> architect's nightmare. All command and control of the entire BMC is done 
> over DBus; we cannot put that on an externally-available address.

I think what you're actually suggesting is that whatever interface is
exposed, it needs authentication/authorisation or for the system design
 to ensure that no unexpected actors can connect.

It's true that the TCP socket option doesn't provide autentication, so
yeah, the suggestion isn't secure, but the suggestion was mainly to
counter the claim that "It doesn't look like the D-Bus spec or libdbus
officially has anything for D-Bus across computers". Support for this
is built into the spec:

https://dbus.freedesktop.org/doc/dbus-specification.html#transports-tcp-sockets

There are other ways to provide authentication and transport security,
so I don't think we have a huge design concern on our hands.

Cheers,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]