On Wed, 2011-01-05 at 13:52 +0100, Lennart Poettering wrote:
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.
Fedora's X has a patch [1] (which I'm almost certain has been posted upstream, and certainly sounded like it had approval at the most recent XDS when it came up) where the X server will simply _pick_ a (set of) display socket(s) not already bound, and tell you what it picked on a file descriptor you pass in from the launching process. Which neatly avoids this kind of DoS, and also eliminates the failure case in gdm that causes the display seizure of doom when X fails to start for other reasons. Right now the only thing using this is the selinux X sandbox, but it's certainly generally applicable.
The deeper problem is that clients authenticate themselves to the server, but then simply trust that the server is the server they were hoping for. If you don't have a process tree relationship (like the gdm +displayfd case) then you have to go all the way to something like Kerberos for that kind of bidirectional auth. Simply moving back to filesystem sockets does not solve that - and indeed, has _more_ DoS conditions than abstract sockets since they don't get garbage-collected on system crash - so simply proscribing the use of abstract sockets seems a little harsh.
(And of course what we're doing here is protecting against a malicious attacker who already has enough privileges to run code on your system, which means you're pretty far into having already lost. Meh.)
[1] - http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=blob_plain;f=x...
- ajax