Is SHA1 cookie authentication broken?

[Julio M. Merino Vidal]

On 8/26/06, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> I think it is broken for the system daemon (that's why it isn't in the
> default config file for the system daemon, also credentials are probably
> more secure). The session daemon uses it though.
>
> > NetBSD lacks socket credentials which prevents D-Bus to work
> > appropriately when connecting to the system daemon:
>
> Are you sure there's no way at all to get credentials from a socket in
> netbsd? Most systems have some kind of way, a couple are supported in
> dbus-sysdeps.c already.

You were right!  There is support for LOCAL_CREDS but unfortunately it
is unimplemented in D-Bus at the moment.

I've been trying to get it to work but have had no luck so far.
Adapting the receiving end to get the credentials is easy, but the
problem I am facing now is the following: for LOCAL_CREDS to work, the
receiver must *first* set this option with setsockopt, and *then* the
sender must send a message (whatever it is -- the null-byte message is
enough).  Only when that order is followed, the receiver gets the
sender credentials.

Now... D-Bus is forcing the connection to go the other way around
because that's what all other credential mechanisms need: first make
the sender send a message and only then let the receiver get it.

I'm having a hard time figuring how this order is forced and how I
could swap it in the LOCAL_CREDS case...  Any pointers?

> > 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.
>
> I think you're right that sha1 cookie doesn't work with the system
> daemon. For creating the cookie in homedirs, probably either the daemon
> needs more privileges or we'd have to write some kind of slave process
> that had more.
>
> For file ownership, seems right to just set it properly, though I
> haven't thought through possible race-condition-based attacks between
> writing the file and changing its permissions, there may be some.
>
> For the system daemon credentials are much preferred on any system that
> has them though...

Indeed.  But given that DBUS_COOKIE_SHA1 is mentioned in the docs one
assumes that it should work.  As long as it does not affect the other
authentication mechanisms in any way (as regards privileges
basically), D-Bus could provide it (disabled by default).  I'll
continue work on my patch, which is almost finished by now.

Cheers,

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