Thanks for the detailed analysis of the technical difficulty of allowing dbus to be restarted. It really does sound like some unfortunate design decisions were made. However, I don't think it would be quite impossible to work around. E.g., the libraries used to connect to dbus could be modified to attempt to silently reconnect, and a replay daemon could record and replay events upon request to allow the reconnecting processes to see what they'd missed. I'll grant that it would be a serious undertaking. On the other hand, it really is a pretty dire situation when patching a dbus security bug is as disruptive to high-availability systems as patching a kernel security bug.
If I might ask, how is this currently handled with unattended-upgrades? The whole point of enabling unattended upgrades for security is to avoid running vulnerable systems, even when the system has no babysitter. This would seem to mandate a triggered unattended reboot. But that's not being done right now; I'm not even sure we have a trigger for that. Just leaving the system vulnerable until a coincidental reboot doesn't seem appropriate. --Barak.
