| |||||||||||||
Ghosts of Unix past, part 4: High-maintenance designsGhosts of Unix past, part 4: High-maintenance designsPosted Nov 26, 2010 16:45 UTC (Fri) by nevyn (subscriber, #33129)In reply to: Ghosts of Unix past, part 4: High-maintenance designs by nix Parent article: Ghosts of Unix past, part 4: High-maintenance designs
> d-bus services (or other started-as-root daemon-invoked processes) have *none* of
> this security-critical quasi-portable crap visible
They don't have _those_ issues, no. But there are a number of open issues wrt. how d-bus services break the link between the user and the service. The most obvious is that loginuid is lost. I've also yet to see any kind of analysis on DOSing D-Bus. These are all security related problems, they are just less well understood.
(Log in to post comments)
Ghosts of Unix past, part 4: High-maintenance designs Posted Dec 2, 2010 22:27 UTC (Thu) by oak (subscriber, #2786) [Link]
> I've also yet to see any kind of analysis on DOSing D-Bus.
DOSing D-BUS is trivial, just register services and send messages.
D-BUS daemon needs an FD per client connection so you can DOS it by creating new connections to it until it doesn't anymore accept connections (it runs out of FDs before you do as it already has several clients).
D-BUS doesn't seem to have limits on its memory usage. For example if you send messages to (e.g. your own) service and it doesn't read them, D-BUS doesn't block either sender or receiver, it just buffers all the messages until the system runs to swap and D-BUS goes OOM.
The D-BUS memory management code seems also a bit horrible, both inefficient (doesn't free memory to system, just fragments its heap) and complicated. It's also a bit strange that a thing that mostly is supposed to push bits from one socket to another is CPU, not IO bound (at least when it has many clients, like you have on Maemo).
|
|||||||||||||