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.
the general lax nature of how endpoints are intended to be defined … is a significant factor for why many applications are the way they are
I feel like this is the same complaint people have about other things, like PHP for example. They see shitty PHP code (like wordpress) and are like: “Oh my god PHP is such a shitty language because this application is written like shit”. But I don’t blame a language, a framework or a protocol for the failures of the users. I don’t feel like an application that close to the system core has to be absolutely “dummy proof”. At some point, we should just expect that people know what they’re doing, and if they don’t, we should blame them, not the underlying technology.
I searched for this and all I got was CVEs in the implementations.
What are the flaws in the protocol that I don’t know of? If you can link it, I would love to read.
I recently started interacting with code that had something to do with D-Bus and from what I saw, there were policy files, which are required to do anything with D-Bus endpoints provided by software. That’s essentially where I stopped, considering that to be the end-all for D-Bus security.
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.
So, first of all, I barely ever had to work with d-bus directly - I used it a few times and it was fine to use.
When I look for “D-Bus Specification”, I get this: https://dbus.freedesktop.org/doc/dbus-specification.html. This LOOKS like a proper documentation of the standard to me.
I feel like this is the same complaint people have about other things, like PHP for example. They see shitty PHP code (like wordpress) and are like: “Oh my god PHP is such a shitty language because this application is written like shit”. But I don’t blame a language, a framework or a protocol for the failures of the users. I don’t feel like an application that close to the system core has to be absolutely “dummy proof”. At some point, we should just expect that people know what they’re doing, and if they don’t, we should blame them, not the underlying technology.
I searched for this and all I got was CVEs in the implementations.
What are the flaws in the protocol that I don’t know of? If you can link it, I would love to read.
I recently started interacting with code that had something to do with D-Bus and from what I saw, there were policy files, which are required to do anything with D-Bus endpoints provided by software. That’s essentially where I stopped, considering that to be the end-all for D-Bus security.
What am I missing?
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.