DBus AUTH Protocol

[Patrick Davis]

The move away from the System bus to a session bus has already been
noted. The original purpose for making the system bus listen in on the
port was ease of use, and the ability for all applications on the server
to talk with remote applications on one bus.

The basic goal is simply connect applications using dbus across a local
area network. Knowing that these connections will be inherently
insecure, a ssh tunnel will be used to secure the traffic. But for
implementation and testing purposes, we have removed the firewall.

The end product will be a server, listening on one port to potentially
multiple apps on different computers, all through ssh tunnels. There
will be one linux machine with apps connecting to the server dbus
daemon, and 0 to many windows machines connecting.

Thanks for the assitance, it sounds like I will have to use a middleman
to accomplish this task, at least until other authentication methods are
introduced into dbus. (There are various problems that prevent me from
patching dbus directly.) Though, you may want to note in the DBUS
Specification Document that only EXTERNAL and DBUS_COOKIE_SHA1 are
implemented.

-Patrick

On Mon, 2007-06-25 at 17:24 -0400, Havoc Pennington wrote:
> Hi,
> 
> Patrick Davis wrote:
> > Here's my problem. I'm trying to get an Application on one computer to
> > connect to the System Bus of another computer.
> 
> This has huge security implications, btw, and you may be better off with 
> your own custom bus (just write a different bus config file, see 'man 
> dbus-daemon') depending on what you are doing.
> 
> > AUTH EXTERNAL 31303030
> > REJECTED EXTERNAL DBUS_COOKIE_SHA1
> > AUTH DBUS_COOKIE_SHA1 6313430306d
> > REJECTED EXTERNAL DBUS_COOKIE_SHA1
> 
> EXTERNAL can't work since it relies on asking the kernel for user 
> authentication, which can't work over TCP, only unix domain sockets.
> 
> > And then the client quits trying to connect. The part I don't
> > particularly understand is that in the system.conf file, EXTERNAL is the
> > only authentication method listed.
> 
> This is because it's the most secure auth method, and the system bus 
> only listens on unix domain sockets by default anyway. Also, COOKIE_SHA1 
> would require the bus daemon to have more privileges:
> 
> > DBUS_COOKIE_SHA1 isn't, and when I
> > explicitly add it to the system bus it causes other applications to
> > fail.
> 
> DBUS_COOKIE_SHA1 relies on the server side (in this case the bus daemon) 
> having read access to private files in user home directories. The auth 
> mechanism is that the client proves to the server that it knows the 
> contents of a cookie file in the user's homedir, and the server then 
> auths the client as that user.
> 
> Most distributions will run the bus daemon as an unprivileged user, so 
> the bus daemon can't read the cookie files. If you run the bus daemon as 
> root, then COOKIE_SHA1 should work, but you have opened a new attack 
> vector (rooting the system bus).
> 
> COOKIE_SHA1 is normally used with the session bus daemon (which runs as 
> the user owning the session, and can thus see the private cookie files).
> 
> > If I remove the <AUTH>EXTERNAL</AUTH> line from the system.conf,
> > enabling all authentication protocols to be used, I still see the same
> > transaction in Wireshark.
> 
> The only two auth mechanisms in 1.0 are EXTERNAL and COOKIE_SHA1. In 
> 1.1.1 (unstable branch), there is also ANONYMOUS, but ANONYMOUS won't 
> work with a bus daemon for now (the bus daemon is coded to require auth 
> as a particular user).
> 
> > So my question is this. What other AUTH protocols are available for
> > DBUS, and how do I use them? I know others are available but there is no
> > documentation anywhere, or at least that I've found, on what they are or
> > how they work. Or is there something I can do to make EXTERNAL or
> > DBUS_COOKIE_SHA1 work with the current setup?
> 
> Basically all you could do is write your own auth mechanism and patch 
> dbus to use it. Without knowing more about what you are trying to 
> accomplish, I can't recommend any mechanism in particular you might want 
> to implement.
> 
> Havoc
>