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.
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.
> hardened stuff that already exist.
To make it even more hardened(?), Google recently contributed and got merged a Rust implementation of binder for the Linux kernel (and they're apparently planning to eventually remove the old C implementation).
https://lwn.net/Articles/953116/
https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...
> also depends on having a obscure Linux feature enabled
An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
> An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development.
Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and also what D-Bus uses, there is just no contest. Even Android uses unix sockets more than Binder.
None of binder is in Java. The Java binder code is just JNI bindings to the native implementation.
Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway.
> Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest.
unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc...
EDIT:
> The other libbinder (openbinder) is dead since 2006ish.
The libbinder I meant is the one in AOSP hence why I said "AOSP is right there":
https://cs.android.com/android/platform/superproject/main/+/...
That one is very definitely not dead since 2006ish.
This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs.
Even the use of C++ is likely to frown many people. (Not me).
https://cs.android.com/android/platform/superproject/main/+/...
[1] BeOS, the docs still match what is in Android :D
OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm.
Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google.
And the rest, as they say, is history.
https://source.android.com/docs/core/architecture/ipc/binder...
https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
Traditional Linux drivers are considered legacy in Android.
Those would have been a great starting point as well! But maybe we'll see them later.
>> 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.
The "friction" is that Wayland developers don't want a sandboxed application with access to the Wayland socket to pwn your machine.
Trying to isolate applications within the same UNIX user is essentially unfixable since there's ptrace, LD_PRELOAD, /proc/$pid, .bashrc drop-ins, etc.
The author must know about all of this, as it's mentioned in the LD_PRELOAD note in the end. In my view, the model he proposes is security by obscurity (putting hurdles on top of a fundamentally insecure system).
At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid.
For example, the kernel could be used[1] to store the secrets in memory and only authorize the userspace process that created it to read it; other processes could request access to a secret and only be given if you accept.
The dbus process is run by and owned by your user. The only people that can access it is you and root. There is a system-wide bus but your secret manager isn't using that one.
It's just this: https://xkcd.com/1200/
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.
KDE had their own IPC thingy, DCOP, but it has been replaced with D-Bus.
For the most part, there's a large ecosystem split between tiling window managers and everything else, and the former is super-tiny in terms of desktop developer reach.
> KPart technology is used in kde to reuse GUI components ... By using kparts in applications developers can spend less time implementing text editor or command line features, for example and just use a katepart or a konsolepart instead.
Now not even Falkon does that.
$ ls -1 /usr/lib/qt6/plugins/kf6/parts | wc -l
20You can't have your cake and eat it too.
ChromeOS has a Linux userspace fully integrated via it's Crostini VM.
Great if everything that one wants from their GNU/Linux experience is a command line and TUI.
Starting a 3D accelerated GUI app? Well, it depends.
So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)
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)
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.
If you're not entering a password at some point, then they're in memory and available to all anyway. If no system prompts or notifies you access is happening, then it's irrelevant what software machinations might be governing this.
iOS and macOS combine sandboxing with their Secure Element. Android uses TEE or a secure element-like piece of hardware. Windows uses a hypervisor + the (f)TPM.
Nothing Linux can't do, it's basically glueing together a small early boot KVM VM + TPM + secure boot together with an API. Setting up your own secure boot keys to make it run relatively seamless is a pain on many consumer devices, though.
The secrets in the keyring of my secure boot protected, full disk encrypted laptop are exactly as secure until I boot it up and unlock the keyring for Dbus.
Windows' Credential Guard (https://learn.microsoft.com/en-us/windows/security/identity-...) is explicitly designed against the "dump all secrets while the system is running" approach.
Even Mimikatz requires exploiting design vulnerabilities and requires administrator access.
If you can break the kernel and all the safeguards the kernel has against secret exfiltration, you may be able to decrypt data from other applications, but it's not like on Linux enviroments where any application running as any standard user can dump the entire credential database by just asking.
On Windows the application can specify some extra entropy/salt, and the secret is not decryptable without it[1]. So it's a tad more difficult to exfiltrate than simply asking for it.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf...
What are people not getting about this? The point of a shared keyring is to enable applications to share secrets. My git tokens are shared between git, my IDE, various scripts etc.
This discussion highlights the exact issue: people don't even understand what problem or use case they are actually solving.
There are secrets I cannot export from my system keychain without disabling SIP on my Mac.
They entered a password to log in probably. And Linux had a setting to restrict ptrace since years.
Imagine if it worked that way for browsers, and every website with a saved-password got to see all the other saved passwords...
> Why is your banking app entering a secret to your keyring?
What is any "keyring" for if not to carry things you keep secret and exclusive?
The problem here is leakage between purposes. I don't care if the banking app is just storing my logon name for convenience, even that should never be scrapeable by Linux BonziBuddy. [0]
> That would be like writing your safe code in a paper and let it hang onto a physical keyring.
Why even put any regular keys onto such a horribly flawed keyring either? There's no real difference between (A) seeing combination-lock numbers versus (B) seeing the shape of a key that is trivial to reconstruct. [1]
In fact, I was attempting that kind of thing just this week, namely trying to run Spotify (distributed as a snap) as separate user in a visible window. Maybe it's possible, but it's certainly not trivial or turnkey.
Respectfully, i think that mostly happens when people reviewing the solution space don't understand the problem fully. Often the requirements differ from what people think they are, and as a result the winner seems random because they don't understand the actual requirements.
On top of that, there's adverse selection here. Who gives up thousands of hours to work on some obscure corner of the Linux desktop? People with quite unusual thought processes.
> the most meritorious solution never rises to the top
You know why? Because it was the best solution at the time that covered everything they needed. You can only complain about it because the initial problem was solved and people were able to move on to something else.
Does it work for what we need it to do? Yes? Ok. Now that we have settled this problem, we can continue on developing.
Meritocracy is only relevant to someone who has ideas but no desire or ability to actually structure the idea in such a way that would work in the world we find ourselves in today.
> Maybe D-Bus has something similar?
So you just commented here to say nothing but "dbus sucks because it isn't the best. I wonder if there are better options?".
> 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?
D-Bus, YOLo!
I dunno man. Emacs is awesome.
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.
Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
> what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway.
Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
> I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Then don't use it? Secure defaults matter for most users.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Find the *kwargs here: https://wayland.app/protocols/xdg-shell
Etc. etc. This isn't the 90s anymore.
And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands.
> Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
In which case they do not connect to the same D-Bus "bus", and the problem is again non-existent. See how flatpak sandoxing does it.
> Then don't use it? Secure defaults matter for most users.
Right until they notice they can no longer view the keyring contents, or any other stupid limitation most desktop users couldn't care about.
In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
> Find the *kwargs here: https://wayland.app/protocols/xdg-shell
Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
If I store my secrets in KWallet, which purports to _storage for secrets_, I absolutely do not expect every application on the desktop to have access to those secrets, whether I want to share them or not.
I can't believe you're suggesting this is sanely defensible.
Kwallet is for encryption at rest, so an attacker can't read your secrets if they steal your computer. It IS NOT protection from your own applications running as the same user.
That's just not how Linux desktop works. It's a desktop operating system, it's not iOS. All apps running as your user have your users permissions.
Is it an outdated security model? Yes, enter sandboxing and newer kernel features. If you're not doing that though then you won't get that.
Just run your shit in flatpak, problem solved. Or better yet, don't install malware and only download trusted open source software from trusted repositories.
The closer you stick to the kernel security model, the more likely your app will be safe and performant, and the less likely other devs will reject it in favor of their hand rolled stuff.
I disagree. With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Would be entirely possible to use this for policy.
> In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. It usually gets keymatter in the form of a user password carried to it from PAM, in order to allow on-disk encryption without needing separate keyring passwords. (And yeah, sure, this could use TPM or something else to avoid the passwords, but the point is literally no different, it shouldn't be each application's job individually to manage their own way of getting secure storage, that's a recipe for data loss and confusion.)
> Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
That's a problem that occurs because the protocols have multiple distinct implementations. Most of the dbus services don't have to deal with that problem at all. (And the ones that do, tend to have problems like this. There are plenty of weird incompatibilities with different XDG desktop portal implementations.)
I'm pretty sure the point of bringing up xdg-shell is because the new bus is inspired by the Wayland protocol. For all of the incessant bitching about Wayland online, Wayland protocols are only about 1000x nicer to use than dbus. You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
The pidfd_open() man page doesn't list many things that can be done with a pidfd. What sort of validation do you have in mind?
I would love to have a reasonably snoop-proof secret storage service whose security model works with normal programs (as opposed to requiring Flatpaks or the like).
I think it would also be feasible to add code signatures if we wanted to, though this would add additional challenges. As I noted elsewhere any scheme that wants to provide a true security boundary here would need to deal with potential bypasses like passing LD_PRELOAD. Still, I think that it has to be taken one step at a time.
Validate what? You're just moving the responsibility to whatever answer you give here. If you say "validate the exec name is firefox-bin" then the next person who comes in will say "I hate $your_new_fangled_ipc, you can make it dump all your secrets by renaming your exec to firefox-bin". (This is just an example).
> And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop.
The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?
If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).
Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .
If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
> You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths. You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want. The policy would obviously vary strongly depending on the system, but if you were dealing with a secure booted system with dm-verity, or something similar, well then this mechanism should be fairly watertight. It's not really the end of the world if there are systems with different security characteristics here.
You can really get creative.
(It is worth noting, though, that this could be bypassed various ways trivially, like with LD_PRELOAD, so to be a true security boundary it would need more thought. Still, this could definitely be made improved numerous ways.)
> The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?
Well, the obvious initial benefit is the same thing that DPAPI has had for ages, which is that it's encrypted on-disk. Of course that's good because it minimizes the number of components that will see the raw secret and ensures that even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.
An additional case worth considering is when the home folder is stored elsewhere over a network filesystem, as in some more enterprise use cases.
> If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).
It would be ill-advised to have each application deal with how to encrypt user data. They can store keymatter in the keyring instead of the data itself if they want to handle storage themselves. (I'm pretty sure this is actually being done in some use cases.)
> Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .
That page exists to explain why they don't bother, but part of that is that there just isn't an option. If there actually was an option, well, it would be different.
> If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
The threat vector is whatever you want it to be, there are plenty of things this could be useful for. The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either. This is probably in part because on Linux most of the programs you run are inherently somewhat vetted by your distribution and considered "trusted" (even if they are subject to MAC like SELinux or AppArmor, like in SuSE) so adding a sandbox feels somewhat superfluous and may be inconvenient (i.e. file access in Bottles is a good example.) But, even in a world where all desktop apps are running in bubblewrap, it's still nice to have extra layers of defense that compliment each other. And even if something or someone does manage to access your decrypted home folder data, it's nice if the most sensitive bits are protected.
> Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
The reason why people don't bother doing this (in my estimation) is because DBus is demoralizing to work on. DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.
And therein lies the rub: if you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.
The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus.
Also I'm puzzled that Polkit hasn't been mentioned even once.
The world is moving towards sandboxed applications (through flatpak and friends) more and more. As per the OP, this is one of the things holding sandboxing back.
Dbus is a godawful mess. Imagine the windows registry, except it can only be inspected at runtime, contains executable binaries and is exceptionally fragile
Those secret stores (gnome-keyring/kwallet) store the secrets encrypted on disk, so every application can read the encrypted secrets but only the secret store has the encryption key to decrypt them. This is held in memory, not on disk.
FreeDesktop-dot-Org would not accept one from the author if he did:
And maybe its time for a reinvention anyway? IPC and efficient and portable formats are very mature nowadays, with protobuf, flatbuffers etc. and the general model of the internet is based around service location, and stuff talking to each other.
I'm kida curious why they didn't go with Unix Sockets in the first place, with named pipes in memory carrying the message transport.
Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
As for it being used everywhere, sure, we had some bad SOAP stuff being used everywhere at one time, but that's not a good thing...
Regarding secrets etc.. on the one hand, yeah it's not much to worry about people with access to your machine reading stuff on your machine, buut*, it's kinda dumb to have stuff encrypted and left around for a public unsecured protocol. The solution would be, for apps that need security, don't use dbus.
If the API was less loosey goosey (self documentating, not so open ended, less awkward), I agree it's fine for applications at the same level of trust to all access the same thing.
The problem is more random scripts off the internet using browser apis to read stuff out of local storage containers. Forcing local containers to explicitly allow such access, and yes, using a non-dbus protocol, would be a preferred method, while not requiring overly complex authentication schemes locally...
Otherwise the main change I would have made would be to explicitly allow applications to access the bus, vs just a random app having access by virtue of running in memory...
No, Linux desktop is just an opportunity for a bunch of special snowflakes to enact their "vision", force their niche requirements on other 99.999% of users or create fiefdoms, where they can feel good and safe.
"it f*cking works"
Can we objectify this claim made here?
Obviously, the components should talk using MCP.
it already annoys me.
an alternative would be welcome.
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.
I think the more important thing is the protocol itself, rather than the specific implementation. As the author notes the current D-bus standards are substandard at best.
I just see a bunch of undocumented C++ code here.
It just needs a catchy name.
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
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.
(Or perhaps even COM)
Considering a sizeable part of Wayland's low-level stuff is written by Drew back in the day, vaxry won't touch anything written by Drew.
This "protocol" effort is to further decouple Hyprland from Wayland infrastructure.
Like everything, this effort is again driven by ego and spite.
>[...]
>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...
It is a bit surprising that xdg-desktop-portal has two very similar APIs that differ in non-obvious and seemingly-arbitrary ways. I was also a bit confused about how the two APIs correspond (or don’t) when I first read their documentation.
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".
I shutdown the connman service and removed it from the auto startup sequence. I manually edited frickin' wpa_supplicant.conf to put my cellphone network there. Worked first time and every time thereafter.
The founding document of GNOME is called "Let's Make Unix Not Suck" by which the authors (primarily Miguel de Icaza) meant "Let's Make Unix Almost Exactly Like Windows". D-Bus is just the latest in a series of attempts to bring Microsoft's janky, kind of an object model to the realm of Unix's small do-one-thing C programs plumbed together with file descriptors, pipes, and network sockets. Except somehow, they added even more problems on top of the ones COM already had!
At least when Steve Jobs tried to retrofit Smalltalk style OOP onto the Unix model, he had the foresight to bring much of Smalltalk (in the form of Objective-C) along with.
I have never heard of that. Even if it was true (and sounds like another security issue); X11 is almost gone for most people. Why should anyone care?
Can you show where you got the impression that "X11 is gone"?
It's "gone" for roughly 80% of the people using Linux on the desktop.
(It's often still installable, it's just no longer the default and has been marked as deprecated / unmaintained.)
That said, there is interest in Wayland in these circles.
https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla...
Their ssh supports the -X and -Y options to run remote X applications.
Let me know when those go Wayland-specific and are able to encompass the new protocol.
Until then, get comfortable in a small and discardable minority.
Also, 20% is quite a big userbase. What you are saying is like saying that Firefox is "gone" because "percentage".
Trust me, X11 is not gone.
(written from a browser that runs in a VNC session that uses the X11 protocol under the hood)
"Trust me, IE6 is not gone" - me
The major DEs have removed their X code paths, or will in the next year. The toolkits will follow suit. X is a dead end for new and non-legacy software.
Wayland was launched 18 years ago and it still can't handle mainstream apps in common scenarios.
Wayland Only (default, installed):
* Fedora
* Ubuntu
* openSUSE
* Arch Linux
* Pop!_OS
Wayland (default)
* Debian
* SUSE
I use Discord on Wayland every day and have for at least 3 years. Both AMD 9060 and NVIDIA 4060 (and an AMD RX 580).
The distro you use can have a huge impact on your OOTB experience.
Even if I didn't depend on such a program myself, I would find it strange that Wayland gives the compositor responsibility for only part of the keyboard: its keys, but not its indicator lights.
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?
Turns out, that's every application, every few minutes, many of them multiple times. Applications like having access to things like refresh tokens so they can download your email, or discover passwords for offering autofill for a website.
I'd welcome many improvements to the Linux status quo, but applications not needing to ask before accessing the bus is the only reason it's usable in the first place.
The reality is no one wants to be prompted everytime for a password. They want it to auto fill.
In complaining about this people are setting the boundary at the wrong place, and in proposing solutions assuming user behavior which doesn't exist (they will absolutely click "yes trust random application I'm busy move along now please").
I do not want to be prompted. I do perhaps want grades of secret access but even then thats asking a lot - do you want my SSH keys? Well yeah I probably want to give them to you some app which is automating things over SSH. It's 5 more versions before you get updates to ship them all to Russia or wherever after an author hand over.
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.
Edit: did some research, I must correct myself, the stealers have indeed evolved so admin permissions are not required for most credentials on Windows either.
However, should "strictly speaking, not really worse than Windows" be the security target we aim for in Linux?
The keyring is pretty open on Windows, if you know the key you can request anything even if stored by another app. There is a way to lock a secret to a specific app but it's not properly enforced in most versions of Windows.
The only user data that would require admin privilege is that of sandboxed Windows Store applications where even the owner can't access it directly from outside the program and you have to be admin.
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.
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.
It’s even more serious than running untrusted shell scripts.
It’s also very common for password manager extensions like 1password and bitwarden.
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...
Still, for user-level systemd, that means the bus is open to any binary running with the user's credentials.
This is not any worse than the risk of running ssh-agent, though.
For Linux, we can do something else, although something similar may be possible. However, it seems that seccomp does not allow the function to send and receive file descriptors, nor to wait for one of any file descriptors in a set (like the "select" function), etc, so it is rather limited, and will require another process to proxy all of these functions. (Wikipedia says seccomp also disables RDTSC; my own system design would not even have such a thing, because I would want to restrict all I/O including high-precision timing; but I would also want to restrict CPUID and stuff like that too.) Capsicum might be better, at least for BSD (although I don't know if it disables RDTSC or CPUID).
I had thought of making a sandbox library tha should not require many changes to the program (although some changes will be needed); this can be used to specify the permissions needed involving files, popen, command-line arguments, network functions, timing, etc, and functions to request input in various character sets, and to request other things as well such as file names, and the host name and port number when connecting to internet, etc.
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.
Well... It is exactly the same.
I was actually looking forward to bus1, such a nice design.
Instead, we are getting varlink it seems. yuk. "json json eggs bacon and json"
systemd-bus 2.0
You could build a viable solution on top of D-Bus though, it's just that apparently nobody bothered so far.
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.
Is there some way to avoid such a mess (and other problems with XDG portals and other XDG stuff) by substituting a .so file, somehow? I don't really know enough about how it works to know whether or not such a thing would work. (Maybe it might work for some programs, depending on which libraries they use for this purpose.)
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.
I'm very thankful for systemd covering more and more bases because the "common" alternatives for many problems might be stable but they are often really bad to configure, maintain and debug - the ergonomics in non-default use cases have a lot of potential for improvement. And what can you do if the maintainer is not responsive to the kind of improvements you would need to make the software ready for the next decades? Many times I have forked things and tried to refactor their technical debt so a new feature can be implemented without making it an even bigger hack, and after that you just want to delete it all and start from scratch with a "proper" setup.
So I can understand the perspective of the systemd developers and the pain they had to go through simply on a technical level, not even thinking about the huge flamewars on mailing lists with some people.
Open source has big social dynamics, and a certain type of person is attracted to being "leader" or maintainer even though they are not as technical as I would wish them to be. I've had the painful experience with having to explain security vulnerabilities to some of them and my idealistic illusion of open source project governance received a good grounding in reality.
On top of this imo the documentation of systemd is really good.
People who think the init system is doing all of this have just not done even the bare minimum amount of research on the topic. Although, granted, the naming might not help.
> Lennart Poettering and Kay Sievers, the software engineers then working for Red Hat who initially developed systemd,[2] started a project to replace Linux's conventional System V init in 2010.[16]
This is wrong, Kay Sievers was working for Novell/SuSE at that time, see https://0pointer.de/blog/projects/systemd.html#faqs
(Mostly because 1) I don't think that the talk page will be paid any attention during the next... millenia.. and 2) I think that you should make the change because you knew that it was incorrect, and have receipts)