Security issues with abstract namespace sockets

Lennart Poettering mzerqung at 0pointer.de
Wed Jan 5 12:52:38 UTC 2011


On Tue, 04.01.11 21:31, Matt McCutchen (matt at mattmccutchen.net) wrote:

> On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote:
> > Of these being used, dbus is correctly implemented, since it randomizes
> > the socket name. Same for gdm.
> 
> The relevant point is not randomness or unguessability, but that dbus
> chooses an available name and passes the actual name being used to
> clients (via the DBUS_SESSION_BUS_ADDRESS environment variable).
> 
> However, even this may not be enough if the session dbus-daemon dies for
> any reason and an attacker takes over the name and sends malicious
> responses.  It would be preferable if process death cases (the
> OOM-killer, even) did not automatically become security holes.  I'm not
> sure how best to solve this.  Wean ourselves from the convenience of the
> abstract namespace and go back to filesystem sockets in places only
> writable by appropriate parties?

That's precisely what I want to tell people: don't use the abstract
socket namespace, unless you really know what you do. The only cases
where it really makes sense to use it is if you have a privileged
service that i sstarted before any user code and never goes away and
hence is not vulnerable to these problems. The D-Bus system bus, the
init systemd and udev are probably the only ones really qualifying for
that. Everything else is restartable.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list