On Wed, 2011-01-05 at 13:52 +0100, Lennart Poettering wrote:
On Tue, 04.01.11 21:31, Matt McCutchen (matt(a)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