Using DBus Daemon with TCP and ANONYMOUS authorization
Schmottlach, Glenn
GSchmott at harmanbecker.com
Mon Nov 17 15:26:31 PST 2008
I have investigated this some more. Perhaps I have been under the
(apparently mistaken ?!?) belief that the DBus daemon will accept TCP
connections from outside the host if the ANONYMOUS authentication tag is
set in the session/system configuration file and the daemon is listening
on a TCP port. It appears this is explicitly prevented by requiring
credentials to be received over all socket connections, whether it is a
local/domain socket or a TCP socket. In my scenario with an external
client trying to connect to a target daemon over TCP, credential
information would not be sent and therefore
_dbus_read_credentials_socket() returns FALSE and the connection
dropped. Is this indeed the correct/expected behavior for the reference
daemon? If true, it seems to diminish the functionality of ANONYMOUS for
those scenarios where you might be willing to accept external
connections. Exactly what would be the use-case where
<auth>ANONYMOUS</auth> would be useful for a daemon listening on a TCP
port?
I've modified dbus/dbus-transport-socket.c @line 374 so that if the
daemon fails to receive credential information via the socket and
anonymous is enabled, then authentication is still allowed.
BEFORE:
if (_dbus_read_credentials_socket (socket_transport->fd,
transport->credentials,
&error))
{
transport->receive_credentials_pending = FALSE;
}
else
{
_dbus_verbose ("Failed to read credentials %s\n",
error.message);
dbus_error_free (&error);
do_io_error (transport);
}
AFTER:
if (_dbus_read_credentials_socket (socket_transport->fd,
transport->credentials,
&error))
{
transport->receive_credentials_pending = FALSE;
}
else if (transport->allow_anonymous)
{
/* Typically a TCP connection won't have any credential
* information. We'll (arbitrarily) just assign the user ID
* of this daemon.
*/
transport->receive_credentials_pending = FALSE;
if (!_dbus_credentials_add_unix_uid
(transport->credentials,
getuid()))
{
_dbus_verbose ("Failed to set UID for anonymous
transport");
do_io_error(transport);
}
}
else
{
_dbus_verbose ("Failed to read credentials %s\n",
error.message);
dbus_error_free (&error);
do_io_error (transport);
}
This seems to work for my scenario (e.g. my external Python client can
now contact services on the host daemon via TCP). Besides the obvious
security hole (e.g. the external client is given the UID of the daemon
itself), can anyone suggest an alternate (and/or better) approach?
-----Original Message-----
From: dbus-bounces at lists.freedesktop.org
[mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Schmottlach,
Glenn
Sent: Monday, November 17, 2008 11:02 AM
To: Havoc Pennington
Cc: dbus at lists.freedesktop.org
Subject: RE: Using DBus Daemon with TCP and ANONYMOUS authorization
Apparently, while following the code in the debugger, if the daemon
can't read the SCM_CREDS information, it's considered a catastrophic
error and the connection is subsequently dropped like a rock.
if (_dbus_read_credentials_socket (socket_transport->fd,
transport->credentials,
&error))
{
transport->receive_credentials_pending = FALSE;
}
else
{
_dbus_verbose ("Failed to read credentials %s\n",
error.message);
dbus_error_free (&error);
do_io_error (transport);
}
The do_io_error() routine appears to actually close the
transport/socket. So it would appear the ANONYMOUS option never gets a
chance to be tried. I'll try digging around dbus-auth.c but it appears
the ANONYMOUS authentication mechanism might be broken at this point.
Please correct me if I'm wrong.
-----Original Message-----
From: dbus-bounces at lists.freedesktop.org
[mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Havoc
Pennington
Sent: Monday, November 17, 2008 10:53 AM
To: Schmottlach, Glenn
Cc: dbus at lists.freedesktop.org
Subject: Re: Using DBus Daemon with TCP and ANONYMOUS authorization
Hi,
On Mon, Nov 17, 2008 at 10:41 AM, Schmottlach, Glenn
<GSchmott at harmanbecker.com> wrote:
> I removed the "EXTERNAL" authentication tag from the session.conf file
> (with only "ANONYMOUS" remaining). Unfortunately, this doesn't appear
to
> have any effect. Here's the stack trace:
>
> 11 _dbus_read_credentials_socket() ..\..\dbus\dbus-sysdeps-unix.c:1140
> 0x080816dc
It may just always read the credentials, but then not use them. Does
this actually cause a problem? If things don't work, are you sure it
isn't some other problem?
> Can you suggest where I might set a breakpoint to see whether or not
the
> ANONYMOUS authentication is being tried? Where does it loop through
the
> configured mechanisms looking for one that works?
Somewhere in dbus-auth.c iirc, though I haven't looked in a couple of
years. It should be pretty simple to find.
Havoc
_______________________________________________
dbus mailing list
dbus at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
_______________________________________________
dbus mailing list
dbus at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
More information about the dbus
mailing list