Security issues with abstract namespace sockets

[Matt McCutchen]

On Wed, 2011-01-05 at 13:52 +0100, Lennart Poettering wrote:
> 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.

But as I said, it's impossible to guarantee that the service never goes
away.  It could crash or get OOM-killed (or terminate before all
potential clients have terminated during system shutdown: is that
possible?), and then you have a security hole.  So I would recommend
filesystem sockets for everything.

-- 
Matt