D-Bus is an IPC mechanism i.e. apps use it to talk to other apps. It’s possible for an attacker to abuse D-Bus to communicate with an app outside of the sandbox and make it execute commands. For example, Jail escape through DBus · Issue #796 · netblue30/firejail · GitHub
D-Bus was not created with isolation in mind.
sandbox-app-launcher cuts off access to D-Bus except the per-sandbox session bus to prevent it from being abused for anything.
dbus is a security risk. Restricting it is via mediation
experimental with Apparmor and Linux 4.21
There was work to create a dbus successor kdbus that went no
where and was dumped.
D-Bus mediation isn’t experimental anymore and is widely used. sandbox-app-launcher uses it and there are even abstractions for it (see /etc/apparmor.d/abstractions/dbus*).
kdbus was just an attempt at getting D-Bus support into the kernel for better performance but it was rejected due to being garbage (similar to the userspace implementation).
Apparmor offers some flexibility for dbus as far as containment. On my system apps that need dbus, the “dbus-accessibility-strict” and “dbus-session-strict” abstractions are useful. The profile for /usr/bin/dbus-daemon is also useful as found in apparmor-profile-everything