Is SHA1 cookie authentication broken?

[Julio M. Merino Vidal]

Hello,

[ To the list administrator: do not accept my pending email with this
same subject.  I have decided to subscribe because otherwise further
discussion would be too slow otherwise. ]

NetBSD lacks socket credentials which prevents D-Bus to work
appropriately when connecting to the system daemon:

dawn:~> dbus-monitor --system
Failed to open connection to system message bus: Did not receive a
reply. Possible causes include: the remote application did not send a
reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.

After some digging I found that the daemon also has a SHA1 cookie
authentication method, so I tried it in the configuration file.
Unfortunately, it didn't work.  To my surprise, it didn't work under
Ubuntu Linux either.

I've been inspecting the code and it seems to have serious issues.

First of all, the daemon typically runs as a non-root user, but the
daemon is in charge of creating the keyrings in the user's home
directories.  As you can imagine, being non-root makes this
impossible.  This can be worked around by configuring the daemon to
run as root in NetBSD.  But I'm afraid of that and a real solution
could be welcome:

Make the daemon not drop the real UID/GID on startup (only the
effective IDs) so that it can regain root privileges later on when it
has to touch the user's keyring (and drop them afterwards).  Could
this be appropriate?  I'm willing to do this work.

Then there is also another problem even if the daemon is run as root.
The daemon creates the keyring files in the user's home directory but
leaves them with incorrect ownerships!  The keyring directory and
files end up owned as root:users in my system.  As a result, and due
to their restrictive permissions (700), the dbus client utility is
unable to open the cookie file and feed it back to the server.

I have fixed this last issue in my local source tree by adjusting the
ownership of the keyring directory and files to those of the caller
(client) just after creation.

Am I right in the items above?  I have some local changes that fix
both items (test suite still not passes though).  It may be also worth
to make the sha1 cookie mechanism optional at build-time so that the
daemon can really drop all privileges when this authentication
procedure is not needed.

Thank you.

-- 
Julio M. Merino Vidal <jmmv84 at gmail.com>
The Julipedia - http://julipedia.blogspot.com/