Unexpected gdbus behaviour during PAM authentication

[Simon McVittie]

On Mon, 16 Jan 2017 at 23:25:50 +0000, David Llewellyn-Jones wrote:
> The advice is appreciated, but could you elaborate on the
> "security-sensitive" part? Apart from being unmaintained, do you know of
> any specific vulnerabilities or potential dangers?

If you use dbus-glib, I'm fairly sure other processes that you communicate
with can make you crash by putting unexpected contents in their messages
(at least some instances of this are design issues that cannot be fixed
while maintaining ABI compatibility). If you don't communicate with any
other processes that you don't already completely trust, then that
isn't such a problem... but it does indicate the sort of code quality
you can expect to find.

If there were known security vulnerabilities beyond that sort of thing,
I'd try to fix them (albeit reluctantly); but it's entirely possible that
my response would be "this can't be fixed, you need to change your code
or stop using dbus-glib".

> However, I'm a bit concerned about conflicting advice. So far, it seems
> dbus-glib, gdbus and libdbus all come with health warnings.

libdbus is low-level, but if the only thing you need to do is a blocking
(synchronous) method call, you've already avoided a lot of the problem
areas; and if you're writing a PAM module, you're already stuck with
writing to some relatively low-level APIs, so you should be used to
it by now :-)

Here is a real-world example of calling some
methods with libdbus, permissively-licensed:
https://cgit.freedesktop.org/dbus/dbus/tree/tools/dbus-update-activation-environment.c
In a PAM module it would likely be safer to use dbus_bus_get_private()
instead of dbus_bus_get(), which would mean you have to
dbus_connection_close() it before you unref it. That would sidestep
any multi-threading or event-loop issues, which are the source of many
of libdbus' health warnings.

GDBus is of good quality and I would generally recommend it, particularly
for large/complex uses of D-Bus (thinking Telepathy and NetworkManager
here). However, it relies on a worker thread: so if your specific use case
has the constraint that starting background threads is unacceptable, then
you can't use it. PAM modules are loaded into arbitrary processes and
provide few guarantees about what the module can expect to find there,
so if you write PAM modules you will get constraints like this.

dbus-glib is like libdbus, but with a layer of (with hindsight) poorly
designed object-orientation thrown over the top. The fixed version of
dbus-glib (which happens to be a rewrite) is GDBus. Unfortunately,
you can't use GDBus because of your "no threads" constraint.

sd-bus is about as low-level as libdbus, but with more "syntactic sugar"
to make it nicer to use from low-level C, and without any attempt at
ability to share a connection between threads. If you only care about
Linux (not *BSD, etc.), consider it. Real-world example of use:
https://github.com/systemd/systemd/blob/master/src/login/pam_systemd.c

    S