Accessing Session Bus through the superuser

[Avery Pennarun]

On Mon, Mar 17, 2008 at 2:58 PM, Havoc Pennington <hp at pobox.com> wrote:
>  On Mon, Mar 17, 2008 at 2:21 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
>  >  It took an awfully long time to invent them, then.  The tradeoff seems
>  >  to be having to remember to unlink() the file,
>
>  It's not about remembering to unlink, it's unlinking period. There is
>  no robust way to be sure the unlink occurs; if the server process is
>  killed, the kernel does not clean up the socket on the filesystem.

This is true of any temporary file used by any program.  It's simple
to just delete the file next time the program starts.

It's easy to tell if a socket file is still in use or not by trying to
connect to it: if the listener is dead, you get ECONNREFUSED, so it's
safe to delete the file.  (There is a slight race condition here if
you're not careful, if multiple copies of the daemon are started
simultaneously.)

>  D-Bus comes with a "dbus-cleanup-sockets" that can be run in a cron
>  job, but, _lame_. Old-style sockets are just sucky if the socket
>  doesn't have a fixed name. (It can't have a fixed name or there's a
>  DOS where someone else creates the per-user name before the user does;
>  the socket has to be in /tmp since homedirs are often on NFS and thus
>  can't have sockets.)

This was news to me so I checked to make sure: at least on Linux 2.6,
NFS-mounted folders *can* contain unix domain sockets.  I just tried
it now, and it's fine.  I'm pretty sure it's been fine for a long
time, as implementing it would likely be harder than not implementing
it.  (Of course you can't talk from one computer to another just
because your unix-domain socket is nfs-mounted.  That would be magic.
But creating an inode with a particular mode is easy, and that's all a
unix domain socket really is on the filesystem.)

>  >  vs. having to implement
>  >  your own security to duplicate what the kernel already does.  I'm not
>  >  sure abstract sockets made the right tradeoff here, especially if
>  >  non-Linux systems using DBus have to use something else anyway.
>
>  It's wrong to think all dbus is doing is replicating the kernel
>  security check. The bus daemon needs to know the UID, not just know
>  that the kernel allowed someone to connect, in order to apply dbus
>  security policies. Moreover, dbus already had to implement auth in
>  order to support TCP.

dbus appears to use a magic-cookie style authentication for TCP, which
is totally different from what it does for Unix sockets.  (Ironically,
this discussion wouldn't have happened if we used the magic-cookie
authentication for the unix-domain session bus, since root can deliver
the magic cookie just fine and would thus be allowed to connect.)

The dbus system bus uses uid-based authentication, but authorizes
different users to do different things, so the more complex behaviour
is desirable.  (Ironically, the system bus uses concrete unix sockets,
not abstract ones, at least on Ubuntu.  Also ironically, this is
probably because of the useful filesystem-level security enforcement
of concrete unix sockets, used here to prevent non-root from listening
on that address.)

The session bus actually implements a completely different third
security policy using a third type of socket.

Have fun,

Avery