jrgd

In reference to the article we’re discussing, I am not entirely talking about vulnerabilities in the implementations, but specifically about the lack of standard security features allegedly not present by design in D-Bus. Namely things like namespace reservation, access controls, and fully-defined transport encryption implementations.

In an environment where desktop security is starting to be taken seriously (see Wayland, freedesktop protocols), D-Bus is lacking by comparison. Pulling from the article, any userland application that implements its own access to the user D-Bus can just dump the contents of your keychain (browser-stored passwords, Signal encryption keys, user contacts, manually stored secrets, etc.). I’d argue that for any untrustworthy application (deliberately run or not), shouldn’t be able to do something like that or otherwise tamper with any application it may feel like.

Flatpak does seem to have ways to limit what applications can access through D-Bus, though I am not entirely sure of the extent of what limits are enforceable. I’ll have to read more into Flatpak’s D-Bus filtering to know exactly what it can and cannot do.

Additionally, D-Bus policies are indeed a form of access control. Unfortunately there are limitations. The first is that they are statically defined config files. If an application desires D-Bus access restriction, the only way for that to happen is if a D-Bus policy file is installed via package manager with the software. Applications are not allowed control over access to their endpoints through D-Bus. Applications can absolutely build an authentication or access control layer on top of their D-Bus endpoints, though without a defined standard this quickly gets into the ‘vendor-specific behavior is encouraged’. (To note, KDE Wallet does this exact thing with an optional access control panel with snitching ability when applications access the user keyring.)

As for the default user session policy (where applications like the user keyring are accessed), things aren’t looking that great. At least on OpenSUSE Leap 16, the session policy is left completely open with zero restrictions by default. This does mean that instead of being standard, every application that wants to use D-Bus is largely left to fend for themselves, which I have no doubt meaning that the level of security afforded can vary wildly between application sets (GNOME, KDE, Hyprland, COSMIC, Cinnamon, etc.). I’d argue this shouldn’t be the case and applications developers shouldn’t have to work around D-Bus in the goal of securely interfacing with it.

To be fair, D-Bus is a protocol. Proper documentation and standards is half of implementation. Without any well-defined standards, a protocol is essentially useless and/or lawless. While not every case of non-compliance is the fault of D-Bus, the general lax nature of how endpoints are intended to be defined as well as the incompleteness for the actual standards applications should adhere to is a significant factor for why many applications are the way they are. In addition to the severe security flaws in D-Bus, this could be written with extensions to the protocol, becoming a new standard. Though if the problems are as deeply rooted as they are, it’s not entirely out of the question to create another standard that isn’t D-Bus.

Revolt rebranded as Stoat and does have voice chat with discord-style hotseat channels available in beta. I still wouldn’t recommend it yet due to client bugs, but it’s getting there.