- cross-posted to:
- hackernews
- cross-posted to:
- hackernews
You must log in or register to comment.
vaxry talked about
LD_PRELOADand I feel like that is a non-issue in this case.
If an attacker has the ability to modifyLD_PRELOADof an application, they already an ability to modify its behaviour without depending upon what D-Bus may let it do.
And if the attacker can changeLD_PRELOADfor a process running as root, they might as well affect the target service directly rather than try doing something with the dbus daemon.Honestly 80% of the article is ranting about developer not writing proper documentation or following specs which is not the fault of D-Bus. The only point that I agree with is the lack of security features, but that has never really been a thing back then. Half of the shit that was developed was completely insecure. Not saying that’s a good thing btw. But that can be fixed.
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.
Without any well-defined standards, a protocol is essentially useless and/or lawless
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.
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.
severe security flaws in D-Bus
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.
I agree with some comments at HN about that proposing an alternative is kinda pointless. D-Bus, contrary to the X situation, can be fixed.
rewrite it in rust
should sort it out :D
Might as well rewrite Shakespeare in Rust, while we are at it :P
Reinventing the wheel won’t help
The wheel is fundamentally broken. D-Bus is unfixable due to its core principles being terrible.
With each passing day Vaxry seems closer and closer to re-implementing the entire userland, I don’t know how he avoids burning out…
Hyperbola has been pointing out problems with dbus for years.
This is quite interesting. I’d been looking into dbus lately and was confused by a few design choices so it makes sense to me that the design is faulty.
Running both simultaneously seems pretty feasible since the session bus bus should be quite lightweight (worse case would be a lot of inter-bus traffic if/when that gets implemented).
Security and kv are excellent features.
I feel it might have more luck gaining adoption if its name did t tie it to hyprland.
Back in 2014 at work we were using and extending dbus-proxy https://github.com/Pelagicore/dbus-proxy because of this weird problem of access rights with D-Bus.
Portals could have been much simpler like how
xdg-openworks.I’m surprised it seems nobody has tried to write an alternative to portals that doesn’t use dbus?
Sounds good, good luck to the dev!
