Problems with D-Bus on the Linux desktop

>> The GNOME project disagrees with this vulnerability report because, according to their stated security model, untrusted applications must not be allowed to communicate with the secret service.

I'd like to point out for anyone on the fence that yes, Gnome is run by clowns in full sized clown shoes.

Why not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus.

You would probably want to write your own service manager, but you can reuse hardened stuff that already exist.

Those would have been a great starting point as well! But maybe we'll see them later.

https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus#what_s_the_difference_...

(no endorsement implied; in particular, ubus has not much of a security model, though OpenWrt has an excuse for that)

So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)

Maybe it should be treated better, not rebooting it every couple of times.

The problem is naturally the Linux desktop fragmentation that hinders a proper full stack approach to application development.

What works for GNOME is useless for KDE, and what works for KDE is useless for XFCE, which is ignored by Sway and so forth.

Well, TIL. Looks like the default GUI for that is `seahorse`, so let's see what I've got on a relatively fresh installation... Looks like mostly Chromium stuff where there's a key that unlocks something more application-specific (e.g. for Discord) and an access token for my JetBrains account.

So no plaintext passwords per se, but now I wonder what a malicious app might uncover if it pursued the local Chromium stuff.

Using http over unix domain sockets, or even making a simple protocol over unix domain sockets with a size header + json payloads is trivial in most languages. Unix domain sockets work with standard linux permissions, you can access them with curl, you can forward them with ssh, you can mount them in containers, etc etc. One socket per service.

D-Bus is an overcomplicated mess all over the place. You have services, interfaces, paths, _and_ methods to classify messages yet messages are still only partially qualified and rely on one connection per message flow. There are return message ids, but some services use polling instead. And even if you have D-Bus you still need to know application-specific protocol details to make any sense of the messages. Application protocols leak wire details into messages (i.e. video access requests duplicate random dbus identifiers in payloads) which makes handling dbus messages generically for e.g. proxying impossible anyway.

> Applications sandboxed via Flatpak only have filtered access to the session bus.

While I see why they think this is a bad answer it really reminds me of this: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31... . Also they did not cite the last statement in their quote and made screenshots, so the quotes are not copyable. Who the hell does that?

I dunno man. Emacs is awesome.

He didn't barge in guns blazing proclaiming "pip is a disgrace" and "it's a fuckin joke". He wrote a tool that was much better and encourage others to try it. Within a year or so, it snowballed into an unstoppable change.

This project currently has a bunch of C++ files, no docs, no tests, no roadmap on how it might replace d-bus, nothing. And as another commenter pointed out, starting a new system service in 2025, yelling about security, and doing this in an unsafe language doesn't inspire confidence.

Lennart Poettering, Theo de Raadt and Linus Torvalds may get away with talking like this, but if you seriosly want to bring a wide community on board (without which the entire thing is a non-starter), look to Charlie instead.

Oh, and also, if you think D-Bus is bad, consider yourself lucky you didn't need to use the thing it replaced - CORBA.

Does it miss a spec? Write one.

Do you really want your secretsd or whatever to only be able to reply to whomever stored the secret? Make clients store a cookie or something and only reply if they prove ownership of it. But I have to ask : what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Or read its files in $XDG_CONFIG_DIR. You are just moving around who has the ultimate responsibility, and that looks like security theater. In addition, I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)

Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.

Etc. Etc.

(Or perhaps even COM)

>[...]

>None of the apps, I repeat, fucking none followed the spec. [...]

>Fun fact: THIS IS STILL THE CASE! The spec advertises a "restore_token" string prop on SelectSources and Start, where no app does this and uses "restore_data" in "options".

Wrong. xdg-desktop-portal has a client API and a compositor API. In the client API the property is called restore_token [1]. In the compositor API the property is called restore_data [2]. Clients do not talk directly to the compositor, they talk to the xdg-desktop-portal application which then talks to the compositor. It is not surprising the the properties would not be called the same.

In the documentation the APIs for app developers and desktop developers are clearly separated on the left hand side [3]. Not only does this have nothing to do with DBus (it would apply to every API where a middleware is used to translate messages), it also shows that the author did not do his due dilligence.

[1]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[3]: https://flatpak.github.io/xdg-desktop-portal/docs/

That when you can open a basic X11 application like xeyes or xterm, you can open any X11 application.

D-bus breaks this.

And it makes my Linux system feel like yet another case of "microservice failure".

If the the protocol is that clean, make a formal specification for it that can be used to generate client code.

A binding to C++ is definitely not what I want in my Go program.

Bahaha. I could have guessed. My only interaction with D-Bus as a layman is xdg-desktop-protocol. Is there just something about that particular use case that makes it so... Obnoxious? I presume all kinds of applications on my computer are right now busily d-bussing away without my notice, but getting xdg-desktop-protocol working with wlroots involved pentagrams and tomes bound in human skin.

Holy shit. I knew conceptually that this was the case but never really took the time to consider the implications.

Pretty much whenever you unlock your keyring all your secrets are accessible by any software that can connect to the bus... How is this acceptable? Are we just supposed to run everything as Flatpak?

It will be interesting to see how it treats symlinks in this case. Or specifically, will this idea break completely for nixos or not.

A better way would be a different operating system design, although without that, you can still improve it on Linux. I think putting secrets in the message bus is not really the way to do sandboxing properly, and I think there should not be a global message bus (it should be specific to a program; if the program is properly sandboxed it can be limited what it can access, and possibly they can be declared by the use of environment variables, although).

There are also problems with the existing sandboxing systems; e.g. some do not work properly with character sets and might not support such things as: popen, command-line arguments of the program to restrict which files can be read/written, etc.

For security for programs running on the same computer communicating with each other while they are running, cryptographic algorithms are probaly not the way to do it; the operating system should handle the security to prevent programs from seeing and/or tampering with something that it is not supposed to do, so that the communication between programs is prevented unless it is configured to allow it.

For the data format, I might use DER (or SDER for the fields that are not required to be in canonical form, since canonical form does not matter for all fields but for some it might matter).

(The implementation would prevent messages from being sent to or received from whoever it is not supposed to be allowed to do, by checking the permissions and/or by just blocking access, forwarding the messages to proxies that might modify and/or log them, etc; such things can potentially make the system more versatile.)

This absolutely terrifies me. Linux desktop security is, to put it politely, nonexistant. And the culture that goes with Linux desktop users just makes things worse, there's still a lot of BOFH gatekeeping going on, laughing at the new users when they inevitably mess something up and worst of all, completely refusing to admit that the Linux desktop has security issues. Whenever a new user asks what antivirus they should run, they are usually met with derision and ridicule, because the (oldschool) Linux users genuinely think their computers are somehow immune and can never be hacked.

The first cybercriminals to put some development effort into Linux ransomware/stealers are going to wreak havoc and a lot of people are going to be in for a rude awakening. The D-Bus issue with secrets in the article is just one of many many many ways in which Linux desktops are insecure by design.

There are of course distros out there that take security seriously, but we are not really seeing new users migrating to Qubes en masse.

Edit: not calling out the distros above in particular, all 3 are doing very good work and are not really any worse in security than most other distros.

This is an education problem and no amount of tech is going to fix it.

Even if dbus didn't have this problem, this is my hardware, I'll do what I want! That's the whole point of Linux.

And yes the default and in particular the glib implementations are horrible. The sdbus implementation is way cleaner.

The claims about "everybody can call everything" are just wrong. There are bus policies and if you care you define them. That being said - the desktop people don't care. But that's not a problem of the dbus design.

Look at CORBA or DCOM. You don't really want that either.

So this gives me pause:

'Ever seen kwallet or gnome-keyring? Yeah, these things. These are supposed to be "secret storage" for things like signing keys, passwords, etc. They can be protected by a password, which means they are secure... right? No. No, they aren't. These secrets may be encrypted on disk, which technically prevents them from being stolen if your laptop is stolen. If you just cringed at that because disk encryption has been a thing for 20 years now or so, you're not alone. However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked. No, this is not a #%&@ing joke. Once you input that password, any app can just read all of them without you noticing."

So, how does systemd ensure that D-Bus commands cannot originate from an unprivileged account?

Does systemd's D-Bus implementation use a different security architecture than stand-alone D-Bus?

I admit that I don't know anything about these mechanisms.

https://www.reddit.com/r/linux/comments/1lxd0hl/systemctl_vs...

dbus is super frustrating to work with: yes!

but what we see here isn't an argument to convince technical people. it's flaming. with no links, no references, just clipping things out of context to make everything look as bad as it can.

dbus actually has policies! the gnome developers aren't saying: there should be no security. they are saying: use the security boundary that we have in place! use allow lists! deny lists! but like every argument in this post, there are no hyperlinks, no references, no way to see in depth what the situation really is: it's a hatchet job, designed not to inform & illuminate, but to cast a shadow over & to conceal the real depths of the issues.

this sort of behavior is garbage, and i have no interest in being in an ecosystem with such fallen, misdirecting, bad behaving deceitfulness. every one of these complaints bends and conceals the complexity of the situation, far more than illuminates bad spots.

there's hundreds or thousands of people who are going to join this dark crusade, going to bandwagon up & break out pitchforks. based off incredibly incomplete misrepresentations of the situation at large. this post is such a wicked harm bringer. this deserves quarantine, needs containment.

I have never heard of D-Bus until today.

SystemD -> SVCHost.exe

Iproute 2 -> You like netsh.exe?

Gnome 3, 4 -> Windows 8 wannabe

Mono -> C# road building path

GConf -> Windows Registry; heck, dconf-editor and gconf-editor look really close.

Can't wait for MMC.exe and GPO editing under Gnome.

Ah, yes, XDG "portals". The reason file selection and screencasting is broken on every new Linux/Wayland installation I do, forcing me to try to understand the insane matrix of supported, half-supported, broken, and unsupported features by the dozen+ different implementations, and come up with the magic configuration incantation that makes it work on my system. Brilliant stuff. But it's secure!

> That is why, I've decided to take matters into my own hands. I am writing a new bus.

Oh, goody. The author quotes xkcd/927 as if anticipating the response, when it's exactly appropriate for this situation.

> For example, with wayland, when you switch, you abandon X. You cannot run an X11 session together with a wayland one, simply not how it works.

Huh? I use niri, and had to install both Xwayland and xwayland-satellite to get some of my apps working. I have no idea what either does, and even less interest in figuring it out, but it sure sounds like some X compatibility layer. Please tell me more about how much X, and now D-Bus, sucks.

I switched to Wayland a few months ago, and I'm happy that things mostly work now, but it seems that reinventing the wheel is the M.O. of developers in the Wayland community. Everyone is tired of everyone else's shit, has a superiority complex as evidenced by this ranty article, and has the urge to recreate literally every tool in the ecosystem that works for their own specific use case. Case in point: the dozens of tools that start with `hypr`. I guess we can add "tavern" now to that, whatever the fuck it is.

I'm tired of the state and direction of modern Linux. I wish I could use OpenBSD and leave this constant churn and bickering behind.

EDIT: Ah, it seems the author agrees with me: https://blog.vaxry.net/articles/2024-linuxInfighting

They're pointing out toxic behavior, favoring constructive criticism, and yet engage in the same behavior they're criticizing. Wild. How we ended up with these people as leaders in the Linux community is beyond me.

> An important part of actually advancing a product forward is to cooperate.

100%. Maybe they should heed their own wisdom.

That's not a surprise. The author of systemd, for instance, is working for Microsoft. Suddenly all those changes to the Linux ecosystem make a lot of sense. It became a corporate commodity, from A to Z. And when that is your objective, it kind of makes sense to have a unified system, even if it is crap.