> However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked
>> 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.
This is especially amazing given how much of wayland friction is in the name of security ("Why would we ever standardise a way to intercept and send keystrokes? it's not secure!")
The security model is that applications run in a sandbox (e.g. Flatpak, snap) and only get D-Bus, Wayland, etc. access via restricted means (e.g. xdg-dbus-proxy).
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).
Yes, it's 100% a security theatre. Programs aren't even allowd to set their own icon because it's not considered secure, I'm not joking. The reasoning goes something like: what if a malicious program set its name to "firefox" and uses the firefox icon and then prompts you for the gmail password, eh?
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.
> Programs aren't even allowd to set their own icon
In GNOME. There is a protocol to set your window icon, and it will be respected by the Wayland compositors which are considering that there is value at having custom icons for each window. GNOME also considers it's confusing to have multiple windows from the same program with different icons, especially since the only places those icons could be displayed on GNOME are in the dock and in the Alt+Tab menu, but you pin apps to the dock, so those custom icons cannot be displayed there when there are multiple windows from the same app.
> 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.
Thats not exactly true since this requires the application to have permission to talk to the secrets service (if using Flatpak)
Sandboxing on the Linux desktop is far from common and the flatpak security is kind of a joke [1] [2], unless something changed recently. For starters, it's the application that has to ask to be sandboxed, so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
> For starters, it's the application that has to ask to be sandboxed
Are you sure about this? My belief was that all flatpak apps run inside a bubblewrap (bwrap) sandbox. I just checked and that's exactly how it runs for me.
> so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
This is done at install time. The application inside the flatpak can't change it on its own. Reputed repositories like Flathub check the permissions and flag them if they are too broad. And you can also change it using something like FlatSeal. This is almost the same permissions model followed by Android.
I agree the flatpak defaults are not at all secure, as they often let the developer choose what to sandbox. I think this is fair, but the user has recourse: you can globally block all installed flatpaks from having access to a specific resource, even if the app "requests" it.
All my apps by defaults have no /home and no network access. I do this by writing to .local/share/flatpak/overrides/global (per user) or /var/lib/flatpak/overrides/global for the system. I wish this was publicized more. The defacto app for flatpak permissions, flatseal, doesn't have this capability yet to my knowledge.
Flatkill is very out of date and disingenuous. Flathub is very explicit and obnoxious about such unsafe permissions and can easily be modified by the user. It's also amusing that people here claim Wayland is a security theater too while posting about flatpak being bad because it's vulnerable to x11 issues.
No security boundary can prevent bad permissions just like in android.
> It's also amusing that people here claim Wayland is a security theater too while posting about flatpak being bad because it's vulnerable to x11 issues.
They both create an illusion of safety. We all know that X.org had no security model and it sucks. Wayland put restrictions that would make sense if the rest of the desktop ecosystem was made with security in mind, but it wasn't. I've heard way too many claims like "Wayland makes keyloggers impossible" that are technically true but irrelevant in the real world, because a desktop environment is not just Wayland.
Flatpack is also misleading and its sanboxing is just not great, regardless of the problem with X11.
> No security boundary can prevent bad permissions just like in android.
Good bringing this up: in Android the applications ask the user for permissions, in flatpak permissions are granted based on what the developed asked. That's just bad.
Program running as user can read data owned by user. If this is a vulnerability then the entire linux userspace is compromised. Can you believe that applications I run can execute gpg2 and steal all my secrets?
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 almost as if the user/group/everyone permission model developed for time sharing mainframes isn’t sufficient anymore for absolutely everything anymore.
Zero disagreement but GNOME I don't think is the one in a position to fix this as I'm not aware of any implementation of the better application level security model that doesn't require a lot of kernel support.
For some reason the OS can manage to ask me about what windows I want to screen share, but not about if i want to share secrets between apps or not? I don't see how this require kernel support - it just needs people recognising it as a problem that is wanting to spend the time actually solving it.
I mean kinda yeah. Literally any program running as your user can connect to dbus, grab your secrets and slurp your home directory. Flatpak 'solves' this issue by putting the program in a sandbox that can't talk directly to dbus and proxies the messages with a filter.
The thing you need the kernel for is to attach meaningful identities to programs and restrict them without needing to sandbox them. And there is a ready made solution to this, one that dbus is already aware of and can use natively. But on systems where it's available a lot of users immediately disable it—SELinux.
I always thought as the secret for things that should not be saved non-encrypted on disk, not for things that should be kept hidden from other applications. And if that is your threat model, you should look into virtual machines.
There are no excuses, this protocol is just terrible: it could have been made much much more secure without any kind of virtualisation or sandboxing.
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.
Fortunately today with AI everyone CAN actually audit all the code for all the software running on their machine themselves by sending it to a black box cloud service, thereby running only software they KNOW they can trust! /s
>I've decided to take matters into my own hands. I am writing a new bus.
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.
Yes! Make something built on top of binder, and use something with orders of magnitude more users and developer resources behind it..
> 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).
Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS.
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.
Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies.
> 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?
Most of binder is in outright Java. Libbinder_ndk is a subset that is unlikely to please anybody. The other libbinder (openbinder) is dead since 2006ish. I actually used this last one in certain commercial product.
> 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":
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).
That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both.
No, it is not. It is the Java class which has native methods that call into the C++ version, as someone said above. But it is still primarily a Java class.
dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
> dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
it does if the only other implementation is basically the JNI native methods of dbus-java. This is what libbinder_ndk looks like from the outside. If there's a newer libbinder that does not look like a Java mess , I have not yet seen it.
Not negating that it may exist; the libbinder you quoted above looks similar to openbinder but I have never used it.
The C++ origin of Binder is annoying, but unlike original Binder[1] easily workable around especially given the exact format of messages is left up for implementation to decide outside few standard bits
[1] BeOS, the docs still match what is in Android :D
Hopefully some distro will implement Android's permission on desktop then. Unix permissions were made for a time where we actually had multiple persons running software in the same OS (a use case that today is served by VMs) rather than protecting an app from another app run by the same user. https://xkcd.com/1200/
Which OS? I didn’t get many results for BSD binder. Then I figured maybe you were joking about the “serious” part, so I tried windows binder, iOS binder, didn’t see much…
Including drivers, as since Project Treble, starting with Android 8 all new drivers are required to be userspace, talking with the kernel via Android IPC (aka Binder).
Traditional Linux drivers are considered legacy in Android.
Well the userspace part of the driver. If they were only userspace they couldn't actually use the hardware. They have to have to be part of Linux or a kernel module to be able to talk to the hardware.
1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
> 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? [...] any app on the bus can read all secrets in the store if the store is unlocked.
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.
Where do you think those secrets are going to be stored otherwise and how are you planning to authenticate to them?
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.
On platforms like Android, iOS, and macOS, secrets are easily stored encrypted with no access to the key unless you exploit the kernel. On Windows, a similar feature is opt-in, but compatibility makes it a little less reliable.
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.
All of that is about protecting secrets at rest on the device. It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
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.
> It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
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.
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.
From what I read here, the problem is that EVIL.app can read your git tokens, too, without you having anything to say about it.
Yes, you want a system that allows sharing of those tokens between various tools, but you also want the user to be in control of which tools can share them.
Android apps can never exfiltrate each other's secrets using the secret manager. Even while the apps are running. Same goes for iOS apps. You can maybe trick them into leaking their session tokens using weird browser exploits, but it's entirely up to the app developer to make that happen.
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.
Keychain access can be limited with ACLs, enforced with code signing signatures as well on iOS and more so on macOS where the “keychain” can still be the older file based type.
There are secrets I cannot export from my system keychain without disabling SIP on my Mac.
When Important Banking App stores a secret to my "keyring", I would never have expected that the "secret" would be trivially available to all other programs that run.
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? That would be like writing your safe code in a paper and let it hang onto a physical keyring.
The problem isn't what's on the keyring, the (reported) problem is that it can be arbitrarily inspected in full by any program. Doors should not be able to enumerate and copy all the keys that aren't meant for them.
> 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]
Unix already have a security model for this: User and Groups. You could create a new user called `banking`. And used that exclusively for any banking activities. Especially with the X11 model where you just have to type `startx` and not have to launch a bazillion software to keep a DE happy.
Have you actually tried that approach, with an individual user for all your programs?
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.
The problem with dbus is also that all these nice browser extensions that integrate websites with gnome/kde talk over dbus. These dbus APIs had several DOS vulnerabilities, some of which could be triggered by visiting any website. It is unacceptable that my desktop environment crashes just because something floods the dbus API, even moreso if it can be triggered by visiting a website.
So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)
I'm guessing the poster meant the USB and Bluetooth browser protocols (which I still find insane how anyone thought those were a good idea, but it's literally the only way to configure some keyboards today).
D-Bus is over 20 years old so a reboot is in order. All this guy's gripes are not legitimate, but many are. However, upgrading desktop infrastructure is just as much about influence (clout) and "social" excellence as it is about technical exellence. A new ipc mechanism that is not backed by the major players has no chance.
I'd argue vaxry _is_ a major player, what with the rise of omarchy.org and r/unixporn, popularizing hyprland enough for him to have enough momentum to publish standards for this new era of TWM linux desktop.
Being a major player in the Linux desktop community is what drives success for these sorts of things. And he's not there right now.
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.
Even within the already small Linux desktop community, the user base of omarchy and extreme customization ('unixporn') is minuscule. The narrative of omarchy or even tiling window managers 'taking over' the desktop world is largely a hyperbolic delusion perpetuated by YouTube influencers and tech bros. For most of them it's just a performance if you watch them struggle navigating it in their videos. The omarchy release video is probably the best example.
This will no doubt be used by many people who use Hyprland and I really don't think Vaxry cares about anything else. He's a college kid from Poland who now is getting enough donations he probably will never have to work for someone else if he doesn't want to, and can just continue developing his own ecosystem.
God I loved kparts, but wasn't that more the idea that everything should be embeddable?
> 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.
Yes it is, but since "KDE 5" I've seen less of it. Besides the obvious example of Konqueror another great example of it was reKonq, which used Akregator, Okular and Kget to handle RSS and PDFs respectively (all within the reKonq window).
Just from the top of my head that I've noticed as a user: several apps, such as Dolphin or Yakuake, use konsolepart; KWrite uses katepart, and Ark uses various parts in its file preview.
> Great if everything that one wants from their GNU/Linux experience is a command line and TUI.
Regular GUI apps work fine on ChromeOS. There's a flag to enable the GPU in the VM and with it, 3D accelerated GUI apps also mostly work. It's not optimized for gaming if that's what you are referring to though.
I wonder if the design of D-Bus has anything to do with a principle I notice a lot, where the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness. For example, I wonder how many repos on github have legitimately created a 100% better framework than React, but the author simply can't get the word out for whatever reason, so the project remains accidentally anonymous. Maybe D-Bus has something similar?
> the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness.
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.
D-Bus came to prominence because of its association with GNOME, which has in turn has remained relevant mostly because of its association with Red Hat.
Over the last couple of decades, Red Hat has been their single largest supporter both in terms of providing cash and employing people to work on GNOME. Their annual reports don’t make it clear, but has this changed?
Most of the time, there is usually no "most meritorious", just something that is elsewhere on the "trade-off space" than the person speaking would like. I usually dismiss everybody who so snidely and arrogantly dismisses results of other people's work(e.g. the OP article), like there was some _obviously_ correct solution that the people who worked on the widely accepted solution were too stupid or malicious to choose. They could not possibly have had other priorities or doing their best to get something working acceptably in a complex ecosystem with no central control, no! They are just dumber than you (or just plain malicious).
Part of what's going on is that all of this stuff is developed by volunteers. If only one person, or three people or whatever, are actually willing to give up hundreds of thousands of hours of their own time to work on something, then those people get to make the decisions about what gets done. There's very little supervision from any kind of "upper management" to catch bad decisions.
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.
iirc it was developed as freedesktop project in order to create standard desktop bus to be used by everybody, as back in a day kde had it's own bus and gnome had another one.
The world is filled with "good enough" solutions. If it has 80% of the functionally needed, it will be good enough for most use cases.
> 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?".
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.
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.
> 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.
> 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 am not a fan of Wayland either, I rather want to be able to run programs from different users against the same application server. This works just fine on Xorg.
A gold standard behaviour for when you want to replace a disfunctional tool/system and will require buy-in from a wide community, is to behave like Charlie Marsh did with ruff and uv.
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.
Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer."
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
> This project currently has a bunch of C++ files, no docs, no tests
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 think one of the point from your parent comment is that something that works for people is a powerful way of making things happen, much more powerful than rants or theory or protocols. I also noticed that with cryptography algorithms/protocol for example: design the most amazing algorithm - no one is going to use it ever if there is no great reference implementation people can use.
> - There's actual standard logic for remotely-existing objects vs. just RPC
Cap'n Proto is an object-capability system that very much has a uniform representation of remote objects. Object references are first-class types. You can send someone a remote object reference, embedded in some other message (e.g. params or return value of another RPC). When they release that reference, you get notified that the object can now be cleaned up.
Is there something else you were looking for here that Cap'n Proto doesn't do?
Not meaning to argue, just curious to understand. (I'm the author of Cap'n Proto.)
> - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases)
FWIW Cap'n Proto objects can implement multiple interfaces. That said, identity of remote objects is a surprisingly complicated subject, and at present it's not necessarily possible to tell whether two references point to the same object.
> - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects)
This is definitely a limitation of Cap'n Proto right now.
> - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems)
There is definitely a lot CORBA does here that Cap'n Proto doesn't. Cap'n Proto itself only defines object lifetimes within the context of an RPC session. Persistence and long-term object identity are left to a higher layer.
Was not aware that Cap'n Proto RPC got object references over network, need to update my knowledge some day (unfortunately for it, it's also not used by any project I need to interact with)
Persistence wasn't really an issue for me, though I am fully aware how popular in many ways it was to look there.
But ready made naming and discovery are somewhat important when:
- I don't want to mess with details of where specific endpoint is etc - with easily available open source CORBA code, I can setup single CORBA Naming service and provide reference to it from all other components, and while I could do it myself, there's a bit of ease to have a pre-existing IDL and basic "initial naming reference" I can utilise
- discovery is more the use of "Trader" service after establishing the naming part.
Essentially, I have few projects where I want to move the current hodge-podge of hard coded parts into a setup where components can be auto detected and auto configured dynamically with minimal effort from me, and with as wide language support as I can get (including Ada and Common Lisp)
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
Can't you guys stop reinventing the wheel every other day? I hate D-Bus like everyone else, even though at least it did bring project Utopia and all such crap. But even if I think it sucks I stay with it for the simple reason that the more alternatives you create the more you annoy other users WAY MORE than any benefit you bring them. D-Bus has been used everywhere from LG TVs to automotives, so at least it f*cking works.
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.
> Make clients store a cookie or something and only reply if they prove ownership of it
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.
> Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
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...
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...
> 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...
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 has never provided any security guarantee, so I dunno what is your surprise here. Its entire premise is centralization and sharing (i.e. not having to type each individual password over and over in each program).
It's literally how it's always worked, and not just on Linux - this is standard across desktop operating systems. Except MacOS, and very recently
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.
Since docker, we know how to do pretty good isolation (some of the tech is shared by Flatpak etc. sandboxes) - just put stuff into different namespaces with some auth api allowing processes to 'mount' the necessary stuff.
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.
> 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.
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.)
> determine the PID of the process that you are talking to and use pidfd to validate where it is coming from.
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).
My reasoning behind the pidfd thing would just be as a way to try to avoid race conditions, though on second thought maybe it's not needed. I think you can take your pick on how exactly to validate the executable. My thought was to go (using /proc/.../exe) check that the file is root owned (and in a root owned directory structure) and then use its absolute path as a key. Seems like it would be a decent start that would get you somewhere on any OS.
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.
> 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.
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.
> 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).
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.
> 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.
Because you do not get it: this is not Android. There is no fixed UIDs. There is no fixed absolute paths. The binaries are not always root-owned. There is no central signing authority (thank god!). You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
> You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want.
Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
> hat 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.
I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
I do not see why you'd have your "sandboxes apps" store their private data but then have another storage that is "more secure" for whatever your definition of secure is.
You'd just put the data in the "more secure" storage to begin with.
What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
> It would be ill-advised to have each application deal with how to encrypt user data.
Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
> 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.
In which case, my entire remark does not apply and there is some (minor) benefit to a keyring.
> 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.
This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
> 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.
I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
> Because you do not get it: this is not Android. There is no fixed UIDs.
Uhhh... I didn't say anything about fixed UIDs.
> There is no fixed absolute paths.
There is if your distribution says there is.
> The binaries are not always root-owned.
They are if your distribution says they are.
> There is no central signing authority (thank god!).
I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.
But anyway. There is if your distribution has one.
> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
There is if your distribution makes there a way to validate something from the PID.
The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.
Immutable distros exist right now.
> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.
> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".
Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.
> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
sigh
You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.
Checking my kdewallet, I can see the following applications:
- KRDC
- Remmina
- KRDP
- Chromium
- krfb
- xdg-desktop-portal
... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.
Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is being used as a dumb key-value store. One that is encrypted automatically without needing the application to do key management.
> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS (where you get a key value store from the app perspective and do neither cryptography nor key management in the app.)
And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.
> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.
But honestly outside of being a smarmy dickhead (sorry, but I never have any reservations firing back when someone is doing it to me) the point I'm making is that if you want DBus to get fixed instead, well, good for you. I would like a Threadripper for Christmas, while we're at it. Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
(And it really doesn't matter to me what Windows or macOS does here honestly. I care about the Linux desktop, not how it compares to whatever crapware Microsoft and Apple are pushing. They haven't really meaningfully improved the desktop in the past 10 years anyways.)
You STILL do not get it: This Is Not Android. Even ignoring that most distributions are not going to do what you want them to do (that's the entire point), the distribution has zero power over what users do. Firefox _is_ still distributed as a simple tarball that you can unpack in your home directory and run.
If flatpak or your distribution suddenly start requiring _root_ so that users can run programs that do not really require root, this not only would be a net security degradation rather than improvement, it would prevent me from using that distribution altogether. And yes, these programs need access to the desktop, the theming service, accessibility, input management, etc. for obvious reasons.
This is why even the current method is superior to anything you are proposing here, and the SCM_CREDENTIALS stuff just does not rightly fit in the Linux desktop model.
> I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Ye
ANY that is source based, for example. Actually, I have not used _any_ distribution that would sign even packages in ages, much less binaries.
Go and check how much love you are going to get if you start asking around for people to sign their own binaries to run them in their machine, to implement a sandboxing mechanism that there are a million other, way less intrusive ways to implement.
> The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not.
It doesn't really matter. A user is then going to mount a $HOME through NFS into a serverbox and expect to run graphical applications from there.
> Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
A problem I fully acknowledge. But how would _any_ D-Bus replacement fix that? You'd need to replace _all_ IPC servers to offer some form of "no longer trust the clients" API (more or less what Wayland supposedly did to X11), and this is a decades-long task _at best_. A different IPC system doesn't really help, and may even delay this!.
> Do you know what "principle of least privilege" is? M
Irrelevant when my point is that I want _my_ privileged process to manage the password keyring itself.
> You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data.
The entire raison-d'être for KWallet was to store AND SHARE passwords amongst programs, as a glorified netrc replacement. The "secure" storage part comes later, and few if any people enable the auto-locking mechanism which is the only thing that can offer any sensible protection to it. As you are aware of, KWallet and gnome-keyring have never provided any level of actual secure storage.
> And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
why do you make this distinction for secrets, and not for literally the rest of extremely critical private data that the app store? Why would user want to backup the passwords but not the private app documents?
"You want a private data storage that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap such private data; [other] individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key."
I mean, from your description, you want KWallet to provide protection so that say the mail client cannot access the browser passwords (something I already disagree with). But don't you also want, in this containerized world, for the mail client to NOT be able to read your browser's history, for example? If you already provide secure, containerized storage for apps, I fail to see any specific distinction between "private app data" and "private app secret" (I would still make the distinction if it was "shared"). You'd want your history to be protected (from other programs) as much as any website password.
I do not even know why you bring up the word "regulation" in here.
> What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd
This is not a reading problem: you are still saying that it is a mess because it is a mess. If you want to break the circular reasoning, you have to introduce an actual reason into the loop.
> Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
You keep framing this as if we were not improving the Linux desktop too, which just shows your bias.
My point: Just don't act like it's weird when the actions only result in a LARGER and more explosive trainwreck rather than an improvement.
The funny/sad detail is that the 80s (at the latest) already solved the problem. Have a look as XDR and Sun RPC. It has both strongly typed APIs and versioning built in. You would have to come up with your authentication mechanism for applications e.g. have them send a cookie file (descriptor).
This is the first time I hear that anyone hates D-Bus. I always saw it as a global API Bus that Apps can register to and which enables some sort of interoperability and automation. After all it can even be used from Bash. What is bad about this?
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 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.
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.
That's only somewhat true if we are talking about the same sandbox nested (which would be quite dumb to do).
Escaping two different sandboxes are multiple times as hard, and a sane sandbox is not trivially picked, see web browsers and that the fact that the world is not one giant botnet.
The reason you do t hear much about it is because it's not an often discussed topic. Nonetheless the hate is there.
Dbus is a godawful mess. Imagine the windows registry, except it can only be inspected at runtime, contains executable binaries and is exceptionally fragile
> 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.
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.
I am puzzled by this comment - hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? That's literally what stuff like Flatpak xdg-desktop-portal and Wayland isolation are built around.
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.
> hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox?
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.
I've never had much luck with it either. A lot of the same pain points as the author.
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...
Putting aside the post and whether it's correct or not.
Reinvent what wheel exactly?
D-Bus can't read your mind (yet) and as such it can't generate an API for you, you still need to design a protocol, it's just that it's on top of D-Bus with certain quirks and restrictions.
Doing the same over UDS in 2025 isn't any more work and doesn't have any negative impact on end users. There's nothing unique about D-Bus from a usability standpoint that can't be done with a service listening over UDS.
This is equivalent to saying that you're reinventing the wheel by not using HTTP as a transport.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Maybe you should look at Varlink. The systemd backed D-Bus alternative. It uses JSON.
Regarding secrets management:
My password manager's protocol is handled using exec and command line arguments. Arbitrary applications can ask for passwords, but they won't get them. They won't read them from disk.
The design of the gnome keyring isn't great, but I actually don't think the protocol matters much in this case.
I may be naive, but why not adopt the browsers api development model. 90% shared core apis, experimental ones, for a few years it seems that every group can work on its code without breaking things for user much while new ideas coming regularly.
Perhaps the SecretManager deserves some extra attention, but I concur. We worked long enough on this, please dont split whats left of the linux desktop...
> Can't you guys stop reinventing the wheel every other day?
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.
You may be joking but I think seriously that may be a decent idea. The universal RPC/automation mechanism which everybody implements-whatever its warts may be-is superior to a better-designed one which few actually end up supporting. You don’t need an LLM to call MCP tools, there’s nothing stopping you from calling MCP tools from any programming language.
Problem is, varlink has been created to alleviate the pain while what I'm looking for here is even more suffering. Perhaps add AI and MCP into the mix. At kernel level with hard dependency on sudo-rs. And local RPC should be blockchain-based.
While there is some valid criticism to be held against D-Bus and its implementations (there's more than one in common use), this article never goes there. It appears to be just an incoherent rambling of someone with poor understanding of how systems work together.
Raises the obvious question of why not using the wayland protocol (on another socket, not on the compositor socket). It has mature implementations in many languages, an IDL with compilers, and every GUI application is already going to link to libwayland anyway.
>Back when I was writing xdg-desktop-portal-hyprland, I had to use a few dbus protocols (xdg portals run on dbus) to implement some of the communication. If we go to the portal documentation, we can find the protocols.
>[...]
>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.
> It is not surprising the the properties would not be called the same.
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.
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.
I don't have dbus installed on my linux due to security and privacy concerns. How is this new bus any better?
- Does it allow applications to enumerate what other apps are installed in the system (connected to the bus), without being explicitly allowed by the admin to do that?
- Does it allow apps to talk to each other without being explicitly allowed by the admin?
- Does it allow apps to "publish" data that anyone can read?
- Does it allow apps to "request" actions from other apps running with other privileges than themselves (elevation of privilege)?
Supported by whom? Xorg, the server, no longer maintained. Also, OpenBSD users already a tiny fraction of users...if every single OpenBSD desktop switches to Linux and Wayland, not a single metric will change significantly.
The `-X` and `-Y` options were a mistake to integrate into `ssh(1)`, it makes an assumption that everybody uses an Athena/X11 type system. That said, you can combine waypipe with ssh to do the same thing (ie. `waypipe ssh` will give you the same effect as `ssh -X`).
> Their ssh supports the -X and -Y options to run remote X applications.
Cool, I remember using it in 2003 a few times. I highly doubt many people going to miss if those were gone. I would not be surprised if the majority of ssh server installations disable x11 session forwarding.
> Until then, get comfortable in a small and discardable minority.
Are you sure you're not confusing Wayland users with OpenBSD users?
X is deprecated. Its maintainers do not want to maintain it. They want you to use Wayland instead.
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.
Are there hard numbers to back up the 80% thing? I don't know one way or the other, I'm just skeptical because I still have applications which don't work correctly under Wayland (Discord), and if I have such problems it wouldn't surprise me if others do too.
I'm not sure why you would need to have "heard of that". If I was getting Linux to work on my computer as many people have, and got xeyes or xterm to work, I would expect other X11 apps to work as well.
Listen in most discussions bringing up security is a good way for you to shut the conversation down, but in the case of IPC anyone who cares enough will be knowledgeable enough to see it for the red herring it is
It is almost gone for me too, except that I can't adjust brightness on my laptop with Wayland. I can with X11. It's a long story but that's the TL;DR of it. So until all of that almost goes away, it's full X11 at least for some people like me.
I was surprised to learn that Wayland still doesn't offer control of keyboard LEDs like Scroll Lock, so unprivileged programs that use those LEDs cannot be ported to Wayland.
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.
After all they started by locking down everything and then they are creating all the openings that real world programs need to do what people use computers for. It's probably a better approach that starting with everything open and attempting to lock down, but it takes a long time and some of us will be locked out by some hardware / software mismatch. In my case it seems that Noveau can't talk properly with the backlight control of my card. Neither X11 can with those new kernel and driver but at least it can use gamma correction to simulate a darker screen. Wayland does not have gamma correction or it doesn't work as it should, I can't remember.
I'm trying a distro with Connman instead of NetworkMangler. It's the same deal. I could not for the life of me get it to connect or even see my cellphone's wifi tethering hotspot.
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.
Are you really thinking of dbus here? It's not in the normal binary loading path. And afterwards, it's not any different from other libraries which may or may not stop the app from functioning for many reasons.
> An important part of adoption will probably be bindings to other languages. The libraries are all in C++, but since they aren't very big (by design), making Rust / Go / Python bindings shouldn't be hard for someone experienced with those languages.
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.
> any app on the bus can read all secrets in the store if the store is unlocked
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?
Funnily enough, my work macOS keychain maimed itself in such a way that I need to recreate it every time I install an OS update. Every time I recreate it, the OS spends a few minutes in a state where every application that needs access to the secrets store requests access through the keychain's password. Incredibly secure!
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.
It's acceptable because flatpak dbus and all its ilk are too opaque for the average "experienced" user to fully grok. The problems are there, but the situation is so convoluted that it's hard to build a mental model unless you truly understand the overall system architecture
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.
> This means that when "/usr/bin/firefox" sets a "passwords:superwebsite.com = animebooba", an app called "~/Downloads/totally_legit.sh" can not see ...
It will be interesting to see how it treats symlinks in this case. Or specifically, will this idea break completely for nixos or not.
I do not like D-Bus either, and I do not like JSON either. Some of the problems are the ones mentioned there, and it has many other problems as well (one of these is that its use of Unicode can cause problems, but there is a lot more problems than just that). I do not agree with the solutions mentioned there either, although they do make some improvements, there are also some problems.
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.)
Could this bus offer a dbus-compatibility 'firewall/translator' d-bus socket per each app (provided they use the d-bus environment variables correctly)? That might speed adoption if it is able to be a drop-in default, instead of needing to run 2 busses.
One more thing: D-Bus has the concept of generic services which can be automatically started, e.g. org.freedesktop.FileManager1. When you send a command to that service, the file manager will be started if it is not already running. However, there is no mechanism for the user to select which file manager to start, so if you happen to have both KDE and GNOME installed you have a 50:50 chance of launching dolphin or nautilus. See for example: https://unix.stackexchange.com/questions/778028/set-a-specif... . It truly boggles the mind.
D-Bus has no concept of generic services. People are using D-Bus to get automatic startup of generic services even though it's not fit for this purpose. It's quite a different thing.
You could build a viable solution on top of D-Bus though, it's just that apparently nobody bothered so far.
>Back when I was writing xdg-desktop-portal-hyprland
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.
So everyone has wanted "year of the Linux desktop" for a while. This year, since Microsoft has decided to call open season on their own feet and Valve has taken a break from swimming in their money pool to make sure absolutely any piece of software ever written can run on Linux, it looks like this might actually be happening. I am seeing a massive influx of new users, driven by distros like Cachy, Nobara, Bazzite. A lot of them don't have previous Linux experience and are generally not the most technically savvy users.
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.
Any windows program you download can steal all your secrets too. The only operating systems that isolate programs by default are on phones (and chromebooks).
Unless you give it admin permissions, it really can't (admittedly, a lot of Windows users do run their computers with their admin account by default). Also, Windows users generally have at least some kind of anti-malware running, which, while not perfect, does work well against most spray-and-pray malware out there.
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?
All your data is owned by your user. If you run a program, it will have access to all your data. Admin or not is irrelevant here.
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.
I think this is missing the main problem with security on a Linux Desktop, the user. All an attacker has to do is to convince the user to run InstallSteamWithAllGamesUnlockedForFree.sh You know, the AnnaKurnikovaSexTape.exe of the windows world.
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.
That's not the problem. The real problem is that if I convince you to run my script, it's going to be quite easy to convince you to give me extra permissions, so I can get to your data. It really irks me when things like Cargo are doing exactly that, make me run a sh script. Cargo and the likes, are making running sh scripts way too common.
I was under the impression that the security concerns there are handled by AppArmor and SELinux (though maybe not granular access control to secrets). Which all desktop Linux installs should be using one or the other, because there's much more than just D-Bus that can be a security risk.
As I understand it, systemctl uses D-Bus to send commands to systemd. I have read that systemd implemented their own D-Bus which is faster than stand-alone D-Bus.
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.
systemd accepts commands from the system bus (i.e. the dbus instance running as uid 0). User desktops have their own session bus, which runs as the user.
Put OS calls on the bus. IMHO we need to add permissions to most user-space APIs so apps don't need to be sandboxed in a VM for security. Is this what SE Linux is? But I sometimes want permission to be granted by the user. For example, I don't want programs to be able to access files unless the user specifies the file - this might be through direct interaction with a GUI, or if we're really smart/tricky enabled if a filename comes on the command line typed by the user. I hope this makes sense, a way to gate system access via normal user input. Is this a reasonable possibility, or am I dreaming too big?
I think the way to do should be capability-based security. However, that is suitable for a new operating system design (and computer design, too, for some reasons).
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.
This is more or less how a lot of it works on macOS via the “Transparency, Consent, and Control” subsystem. Even non-sandboxed apps cannot just go rooting around my Desktop without the OS throwing a popup up asking me if it’s ok.
I never took d-bus seriously because they said that when dbus was updated you could not just restart the dbus daemon, you were required to hard reboot.
> Back when I was writing xdg-desktop-portal-hyprland
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.
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.
> 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!
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.)
I have a very vague familiarity with how it works, but I don't think there are alternatives. If you're using Wayland, you either have to rely on a distro or DE to configure it for you, or do it yourself.
To be fair: I don't think the idea behind portals is necessarily bad. But the half-baked implementations that all do things slightly differently is a pretty bad UX overall.
Oh, it works for me too, but unless you're using a distro or DE that preconfigures it for you, you have to do it yourself. Which I'm used to on Void Linux and usually don't mind, but it's a horrendous UX that I just didn't have to deal with on X11.
We need a protocol, not an implementation, so language is a minor detail nobody should need to care about. It should be easy to use implement by lib developers in various languages, and easy to use for app developers. It should be designed to work on all OSs, even if not all platforms will support it yet.
We may need both actually: solid protocol and great reference implementation.
Wayland was advertised as protocol mostly. After almost 20 years, it still has not promised to be a full replacement to xorg and probably never will, where wayland developers say "this is not our goal". Took people quite some time to realise that; it's been more recently become obvious, but say, 12 years ago few understood this.
I still have not been able to find working replacements to all that works on xorg, for instance; specifically imagemagick is different on wayland. I may try again at a later point in time, but my old workings there did not work, and replacements seem dead or ineffective or incomplete - that is quite frustrating for something that was aggressively advertised as "this is now the future".
100% agree, I should have phrased it less black and white. In theory a spec is all you need but in practice solid reference implementations can iron out ambiguity plus it can uncover issues in the spec.
Not everyone wants to recompile the whole app and dependencies with filc to get a slowdown, extra memory use and safety. It's cool that it exists, but omitting the tradeoffs when pushing this is weird.
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
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 vocal critic of microsoft but systemd/wayland was one of the best things to happen to linux. If you can improve upon it, then feel free to implement a better solution.
A solution to what? Aside from details of the implementation, one can also disagree with the framing of the problem and scope of the solution. Sure, we're free to implement an alternative solution for doing DNS resolution and IPC and logging and time synchronization and job scheduling and service monitoring and ... but should there be a single solution to all of these things at once?
All of the things you mention are interdependent, as resource and service management is the core of it all. I'm convinced that they set out to design somethign that has a scope which is as small as possible, but then noticed that interfacing with legacy-but-established open source software was extremely difficult.
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.
It's literally not a single solution. systemd isn't a piece of software, it's, like, 20 pieces of software.
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.
Right, I guess I shouldn't have edited out my preemptive response to this: Of course the solution is internally composed of different parts. Most things are. People of course understand that those internal parts could be switched out for new parts that perform the same role in the overall solution, but that doesn't help when the disagreement is about the scope and purpose of the entire solution.
When people talk about systemd being a big ole monolith against the unix philosophy this is usually what they mean. And it's just not true. Like, theres no argument to be had because systemd is many pieces of software that do one thing.
My point was there is no systemd software. Systemd is a project naming convention with many projects under its umbrella that do not rely on each other in any way.
It's sort of like saying KDE is a whole thing because it has a text editor. Uh, no - KDE is a project, Kate is a text editor part of the k applications suite, which has nothing to do with plasma, the desktop shell. You can use Kate on any shell. You can use plasma without Kate.
Wherever they might be working now.. isn't really relevant to the project
> 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]
A note about this conversation. and your improvements has been added to the "talk" page - Can I recommend that you make the appropriate change to the actual page?
(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)
> However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked
>> 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.
This is especially amazing given how much of wayland friction is in the name of security ("Why would we ever standardise a way to intercept and send keystrokes? it's not secure!")
The security model is that applications run in a sandbox (e.g. Flatpak, snap) and only get D-Bus, Wayland, etc. access via restricted means (e.g. xdg-dbus-proxy).
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).
Yes, it's 100% a security theatre. Programs aren't even allowd to set their own icon because it's not considered secure, I'm not joking. The reasoning goes something like: what if a malicious program set its name to "firefox" and uses the firefox icon and then prompts you for the gmail password, eh?
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.
> Programs aren't even allowd to set their own icon
In GNOME. There is a protocol to set your window icon, and it will be respected by the Wayland compositors which are considering that there is value at having custom icons for each window. GNOME also considers it's confusing to have multiple windows from the same program with different icons, especially since the only places those icons could be displayed on GNOME are in the dock and in the Alt+Tab menu, but you pin apps to the dock, so those custom icons cannot be displayed there when there are multiple windows from the same app.
> 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.
Thats not exactly true since this requires the application to have permission to talk to the secrets service (if using Flatpak)
Sandboxing on the Linux desktop is far from common and the flatpak security is kind of a joke [1] [2], unless something changed recently. For starters, it's the application that has to ask to be sandboxed, so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
[1]: https://flatkill.org/ [2]: https://hanako.codeberg.page/
> For starters, it's the application that has to ask to be sandboxed
Are you sure about this? My belief was that all flatpak apps run inside a bubblewrap (bwrap) sandbox. I just checked and that's exactly how it runs for me.
> so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
This is done at install time. The application inside the flatpak can't change it on its own. Reputed repositories like Flathub check the permissions and flag them if they are too broad. And you can also change it using something like FlatSeal. This is almost the same permissions model followed by Android.
I agree the flatpak defaults are not at all secure, as they often let the developer choose what to sandbox. I think this is fair, but the user has recourse: you can globally block all installed flatpaks from having access to a specific resource, even if the app "requests" it.
All my apps by defaults have no /home and no network access. I do this by writing to .local/share/flatpak/overrides/global (per user) or /var/lib/flatpak/overrides/global for the system. I wish this was publicized more. The defacto app for flatpak permissions, flatseal, doesn't have this capability yet to my knowledge.
Flatkill is very out of date and disingenuous. Flathub is very explicit and obnoxious about such unsafe permissions and can easily be modified by the user. It's also amusing that people here claim Wayland is a security theater too while posting about flatpak being bad because it's vulnerable to x11 issues.
No security boundary can prevent bad permissions just like in android.
> It's also amusing that people here claim Wayland is a security theater too while posting about flatpak being bad because it's vulnerable to x11 issues.
They both create an illusion of safety. We all know that X.org had no security model and it sucks. Wayland put restrictions that would make sense if the rest of the desktop ecosystem was made with security in mind, but it wasn't. I've heard way too many claims like "Wayland makes keyloggers impossible" that are technically true but irrelevant in the real world, because a desktop environment is not just Wayland.
Flatpack is also misleading and its sanboxing is just not great, regardless of the problem with X11.
> No security boundary can prevent bad permissions just like in android.
Good bringing this up: in Android the applications ask the user for permissions, in flatpak permissions are granted based on what the developed asked. That's just bad.
>applications ask the user for permissions
Such portals exist for some permissions like screensharing and other are planned.
https://tesk.page/2021/02/11/response-to-flatkill-org/
Program running as user can read data owned by user. If this is a vulnerability then the entire linux userspace is compromised. Can you believe that applications I run can execute gpg2 and steal all my secrets?
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/
It’s almost as if the user/group/everyone permission model developed for time sharing mainframes isn’t sufficient anymore for absolutely everything anymore.
Zero disagreement but GNOME I don't think is the one in a position to fix this as I'm not aware of any implementation of the better application level security model that doesn't require a lot of kernel support.
For some reason the OS can manage to ask me about what windows I want to screen share, but not about if i want to share secrets between apps or not? I don't see how this require kernel support - it just needs people recognising it as a problem that is wanting to spend the time actually solving it.
I mean kinda yeah. Literally any program running as your user can connect to dbus, grab your secrets and slurp your home directory. Flatpak 'solves' this issue by putting the program in a sandbox that can't talk directly to dbus and proxies the messages with a filter.
The thing you need the kernel for is to attach meaningful identities to programs and restrict them without needing to sandbox them. And there is a ready made solution to this, one that dbus is already aware of and can use natively. But on systems where it's available a lot of users immediately disable it—SELinux.
There's precious little evidence of these sort of things being problems for linux desktop users, in practice.
Because no one cares about 3% of desktop users, when much juicier and larger targets also exist.
I always thought as the secret for things that should not be saved non-encrypted on disk, not for things that should be kept hidden from other applications. And if that is your threat model, you should look into virtual machines.
There are no excuses, this protocol is just terrible: it could have been made much much more secure without any kind of virtualisation or sandboxing.
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.
[1]: https://docs.kernel.org/security/keys/core.html
That’s exactly what it’s for. Parent is just being rude for no reason.
[dead]
Fortunately today with AI everyone CAN actually audit all the code for all the software running on their machine themselves by sending it to a black box cloud service, thereby running only software they KNOW they can trust! /s
"works as intended wontfix conversation locked"
>I've decided to take matters into my own hands. I am writing a new bus.
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.
Yes! Make something built on top of binder, and use something with orders of magnitude more users and developer resources behind it..
> 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-...
There are few implementations of the Binder userspace outside of Android.
Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS.
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.
How many implementations existed of their new bus?
Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies.
> 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?
Most of binder is in outright Java. Libbinder_ndk is a subset that is unlikely to please anybody. The other libbinder (openbinder) is dead since 2006ish. I actually used this last one in certain commercial product.
> 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.
> Most of binder is in outright Java
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.
"None of binder is in Java" is too strong a statement: https://android.googlesource.com/platform/frameworks/base/+/...
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).
That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both.
https://cs.android.com/android/platform/superproject/main/+/...
No, it is not. It is the Java class which has native methods that call into the C++ version, as someone said above. But it is still primarily a Java class.
dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
> dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
it does if the only other implementation is basically the JNI native methods of dbus-java. This is what libbinder_ndk looks like from the outside. If there's a newer libbinder that does not look like a Java mess , I have not yet seen it.
Not negating that it may exist; the libbinder you quoted above looks similar to openbinder but I have never used it.
The C++ origin of Binder is annoying, but unlike original Binder[1] easily workable around especially given the exact format of messages is left up for implementation to decide outside few standard bits
[1] BeOS, the docs still match what is in Android :D
Not entirely , you need to agree on some constraints for wire protocol since the kernel ends up doing reference counting on objects sent through it.
That was in the "few standard bits", yes.
Just use Android's implementation
Isn't that tightly tied to the Android permission and app model, which is radically different from generic Linux.
Hopefully some distro will implement Android's permission on desktop then. Unix permissions were made for a time where we actually had multiple persons running software in the same OS (a use case that today is served by VMs) rather than protecting an app from another app run by the same user. https://xkcd.com/1200/
Which OS? I didn’t get many results for BSD binder. Then I figured maybe you were joking about the “serious” part, so I tried windows binder, iOS binder, didn’t see much…
Binder is the primary way apps talk to the various OS services on Android.
https://source.android.com/docs/core/architecture/ipc/binder...
https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
Including drivers, as since Project Treble, starting with Android 8 all new drivers are required to be userspace, talking with the kernel via Android IPC (aka Binder).
Traditional Linux drivers are considered legacy in Android.
Well the userspace part of the driver. If they were only userspace they couldn't actually use the hardware. They have to have to be part of Linux or a kernel module to be able to talk to the hardware.
https://source.android.com/docs/core/architecture/ipc/binder...
Binder will come to linux desktop soon... together with Android :)
Is there any plans by some DE to replace D-bus with Binder?
Is Binder better than D-Bus? How so?
1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
From the style of this article I expected that https://github.com/hyprwm/hyprwire and https://github.com/hyprwm/hyprtavern would have documentation, specification and perhaps a bunch of tests, but they're not really there (other than smoke tests).
Those would have been a great starting point as well! But maybe we'll see them later.
I believe the sole author is doing finals for their last year of university at the moment.
tbf they stated in their article that those are not there YET multiple time. We'll wait and see once they're done
OpenWrt devs had this epiphany many years ago:
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)
> 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? [...] any app on the bus can read all secrets in the store if the store is unlocked.
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.
Where do you think those secrets are going to be stored otherwise and how are you planning to authenticate to them?
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.
On platforms like Android, iOS, and macOS, secrets are easily stored encrypted with no access to the key unless you exploit the kernel. On Windows, a similar feature is opt-in, but compatibility makes it a little less reliable.
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.
All of that is about protecting secrets at rest on the device. It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
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.
> It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
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...
Which is still protecting secrets at rest.
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.
From what I read here, the problem is that EVIL.app can read your git tokens, too, without you having anything to say about it.
Yes, you want a system that allows sharing of those tokens between various tools, but you also want the user to be in control of which tools can share them.
Android apps can never exfiltrate each other's secrets using the secret manager. Even while the apps are running. Same goes for iOS apps. You can maybe trick them into leaking their session tokens using weird browser exploits, but it's entirely up to the app developer to make that happen.
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.
Keychain access can be limited with ACLs, enforced with code signing signatures as well on iOS and more so on macOS where the “keychain” can still be the older file based type.
There are secrets I cannot export from my system keychain without disabling SIP on my Mac.
You believe any Android or iOS app can exfiltrate all stored secrets?
> If you're not entering a password at some point, then they're in memory and available to all anyway.
They entered a password to log in probably. And Linux had a setting to restrict ptrace since years.
When Important Banking App stores a secret to my "keyring", I would never have expected that the "secret" would be trivially available to all other programs that run.
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? That would be like writing your safe code in a paper and let it hang onto a physical keyring.
The problem isn't what's on the keyring, the (reported) problem is that it can be arbitrarily inspected in full by any program. Doors should not be able to enumerate and copy all the keys that aren't meant for them.
> 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]
[0] https://en.wikipedia.org/wiki/BonziBuddy
[1] https://en.wikipedia.org/wiki/Bitting_(key)
Unix already have a security model for this: User and Groups. You could create a new user called `banking`. And used that exclusively for any banking activities. Especially with the X11 model where you just have to type `startx` and not have to launch a bazillion software to keep a DE happy.
Have you actually tried that approach, with an individual user for all your programs?
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.
That's what Android does. Desktop Linux should make this easier.
The problem with dbus is also that all these nice browser extensions that integrate websites with gnome/kde talk over dbus. These dbus APIs had several DOS vulnerabilities, some of which could be triggered by visiting any website. It is unacceptable that my desktop environment crashes just because something floods the dbus API, even moreso if it can be triggered by visiting a website.
So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)
What browser extensions? Why would I want websites to integrate with gnome or kde? What does that even mean?
Isn’t this bad boy installed by default in most Gnome distros? https://chromewebstore.google.com/detail/gnome-shell-integra...
I'm guessing the poster meant the USB and Bluetooth browser protocols (which I still find insane how anyone thought those were a good idea, but it's literally the only way to configure some keyboards today).
Those are not extensions. Not can you use them to talk to dbus.
Not an issue with a standalone VM :D
Now you have two problems.
s,VM,WM, sorry. No, not two problems; I can always spawn whatever tool requiring dbus with dbus-launch while keeping my window manager aside.
D-Bus is the closest Linux desktop has from XPC, COM, Android IPC.
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.
> 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.
Yep, using Linux in various forms since 1995.
D-Bus is over 20 years old so a reboot is in order. All this guy's gripes are not legitimate, but many are. However, upgrading desktop infrastructure is just as much about influence (clout) and "social" excellence as it is about technical exellence. A new ipc mechanism that is not backed by the major players has no chance.
I'd argue vaxry _is_ a major player, what with the rise of omarchy.org and r/unixporn, popularizing hyprland enough for him to have enough momentum to publish standards for this new era of TWM linux desktop.
Being a major player in the Linux desktop community is what drives success for these sorts of things. And he's not there right now.
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.
Even within the already small Linux desktop community, the user base of omarchy and extreme customization ('unixporn') is minuscule. The narrative of omarchy or even tiling window managers 'taking over' the desktop world is largely a hyperbolic delusion perpetuated by YouTube influencers and tech bros. For most of them it's just a performance if you watch them struggle navigating it in their videos. The omarchy release video is probably the best example.
Honestly, who cares?
This will no doubt be used by many people who use Hyprland and I really don't think Vaxry cares about anything else. He's a college kid from Poland who now is getting enough donations he probably will never have to work for someone else if he doesn't want to, and can just continue developing his own ecosystem.
actually kde has kparts which are somewhat like com. prior to d-bus kde used to use dcop.
God I loved kparts, but wasn't that more the idea that everything should be embeddable?
> 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.
https://techbase.kde.org/Development/Tutorials/Using_KParts
Yes it is, but since "KDE 5" I've seen less of it. Besides the obvious example of Konqueror another great example of it was reKonq, which used Akregator, Okular and Kget to handle RSS and PDFs respectively (all within the reKonq window).
Now not even Falkon does that.
Just from the top of my head that I've noticed as a user: several apps, such as Dolphin or Yakuake, use konsolepart; KWrite uses katepart, and Ark uses various parts in its file preview.
It does, but again only usable by KDE apps.
The fragmentation is a natural consequence of different use cases existing.
You can't have your cake and eat it too.
Which is why in the end, WSL 2.0 is the Year of Desktop Linux, while Android, WebOS and ChromeOS commonality is the Linux kernel, not userspace.
> ChromeOS commonality is the Linux kernel, not userspace.
ChromeOS has a Linux userspace fully integrated via it's Crostini VM.
Partially, because not everything actually works, depending on the Chromebook model.
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.
> Great if everything that one wants from their GNU/Linux experience is a command line and TUI.
Regular GUI apps work fine on ChromeOS. There's a flag to enable the GPU in the VM and with it, 3D accelerated GUI apps also mostly work. It's not optimized for gaming if that's what you are referring to though.
I wonder if the design of D-Bus has anything to do with a principle I notice a lot, where the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness. For example, I wonder how many repos on github have legitimately created a 100% better framework than React, but the author simply can't get the word out for whatever reason, so the project remains accidentally anonymous. Maybe D-Bus has something similar?
> the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness.
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.
D-Bus came to prominence because of its association with GNOME, which has in turn has remained relevant mostly because of its association with Red Hat.
No, it remained relevant because Ubuntu based every stack for their desktop on GNOME technologies (except the aborted Unity 8).
Over the last couple of decades, Red Hat has been their single largest supporter both in terms of providing cash and employing people to work on GNOME. Their annual reports don’t make it clear, but has this changed?
Most of the time, there is usually no "most meritorious", just something that is elsewhere on the "trade-off space" than the person speaking would like. I usually dismiss everybody who so snidely and arrogantly dismisses results of other people's work(e.g. the OP article), like there was some _obviously_ correct solution that the people who worked on the widely accepted solution were too stupid or malicious to choose. They could not possibly have had other priorities or doing their best to get something working acceptably in a complex ecosystem with no central control, no! They are just dumber than you (or just plain malicious).
https://en.wikipedia.org/wiki/Worse_is_better
Part of what's going on is that all of this stuff is developed by volunteers. If only one person, or three people or whatever, are actually willing to give up hundreds of thousands of hours of their own time to work on something, then those people get to make the decisions about what gets done. There's very little supervision from any kind of "upper management" to catch bad decisions.
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.
Worse is better, but meta, because the worst way of choosing is what wins
iirc it was developed as freedesktop project in order to create standard desktop bus to be used by everybody, as back in a day kde had it's own bus and gnome had another one.
D-Bus has the weight of Redhat behind it.
It's just politics, really.
The world is filled with "good enough" solutions. If it has 80% of the functionally needed, it will be good enough for most use cases.
> 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?".
There is definitely an elite cabal with its thumb on the scale here.
And the prevalance of D-Bus is part of it...? Spill the beans!
The deep state forcing everybody to use GNOME smh my head
this post has killed my interest in hyprland.
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.
Why is a generic bus protocol even needed?
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.
> 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.
> 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?
Wayland, thow shall not screenshot without root.
D-Bus, YOLo!
I am not a fan of Wayland either, I rather want to be able to run programs from different users against the same application server. This works just fine on Xorg.
Works just fine on Wayland as well. It's simply a Unix socket that you can set permissions for, it's even easier than X11 with its magic cookies.
A gold standard behaviour for when you want to replace a disfunctional tool/system and will require buy-in from a wide community, is to behave like Charlie Marsh did with ruff and uv.
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.
Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer."
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
Aint that the truth. D-Bus isnt that terribly shit either, we just need to solve this SecretManager issue...
> This project currently has a bunch of C++ files, no docs, no tests
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 can get on board with that if there's a protocol spec - at least a draft or something more tangible than "it's a tavern".
I just see a bunch of undocumented C++ code here.
I think one of the point from your parent comment is that something that works for people is a powerful way of making things happen, much more powerful than rants or theory or protocols. I also noticed that with cryptography algorithms/protocol for example: design the most amazing algorithm - no one is going to use it ever if there is no great reference implementation people can use.
At this point I would like CORBA back.
Yes! And always put the network first. Some kind of "network object model environment" is needed where servives can be somewhere on your network.
It just needs a catchy name.
GNOME 1.x was in many ways a dream, a dream I noticed was killed but haven't finished its death throes back when 2.4 was released
That would be Cap'n Proto RPC
No thanks, all the reasons I ended up looking at CORBA recently are because of things that simple RPC libs like Cap'n Proto don't do.
Out of curiosity, like what?
- There's actual standard logic for remotely-existing objects vs. just RPC
- An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases)
- Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects)
- Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems)
That's just quick throw from memory.
> - There's actual standard logic for remotely-existing objects vs. just RPC
Cap'n Proto is an object-capability system that very much has a uniform representation of remote objects. Object references are first-class types. You can send someone a remote object reference, embedded in some other message (e.g. params or return value of another RPC). When they release that reference, you get notified that the object can now be cleaned up.
Is there something else you were looking for here that Cap'n Proto doesn't do?
Not meaning to argue, just curious to understand. (I'm the author of Cap'n Proto.)
> - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases)
FWIW Cap'n Proto objects can implement multiple interfaces. That said, identity of remote objects is a surprisingly complicated subject, and at present it's not necessarily possible to tell whether two references point to the same object.
> - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects)
This is definitely a limitation of Cap'n Proto right now.
> - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems)
There is definitely a lot CORBA does here that Cap'n Proto doesn't. Cap'n Proto itself only defines object lifetimes within the context of an RPC session. Persistence and long-term object identity are left to a higher layer.
Was not aware that Cap'n Proto RPC got object references over network, need to update my knowledge some day (unfortunately for it, it's also not used by any project I need to interact with)
Persistence wasn't really an issue for me, though I am fully aware how popular in many ways it was to look there.
But ready made naming and discovery are somewhat important when:
- I don't want to mess with details of where specific endpoint is etc - with easily available open source CORBA code, I can setup single CORBA Naming service and provide reference to it from all other components, and while I could do it myself, there's a bit of ease to have a pre-existing IDL and basic "initial naming reference" I can utilise
- discovery is more the use of "Trader" service after establishing the naming part.
Essentially, I have few projects where I want to move the current hodge-podge of hard coded parts into a setup where components can be auto detected and auto configured dynamically with minimal effort from me, and with as wide language support as I can get (including Ada and Common Lisp)
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
I dunno man. Emacs is awesome.
I don't think they implied that old software is always bad.
Plenty of the implementation not so much, however.
Can't you guys stop reinventing the wheel every other day? I hate D-Bus like everyone else, even though at least it did bring project Utopia and all such crap. But even if I think it sucks I stay with it for the simple reason that the more alternatives you create the more you annoy other users WAY MORE than any benefit you bring them. D-Bus has been used everywhere from LG TVs to automotives, so at least it f*cking works.
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.
> Make clients store a cookie or something and only reply if they prove ownership of it
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.
> Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
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...
> 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...
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 has never provided any security guarantee, so I dunno what is your surprise here. Its entire premise is centralization and sharing (i.e. not having to type each individual password over and over in each program).
It's literally how it's always worked, and not just on Linux - this is standard across desktop operating systems. Except MacOS, and very recently
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.
Since docker, we know how to do pretty good isolation (some of the tech is shared by Flatpak etc. sandboxes) - just put stuff into different namespaces with some auth api allowing processes to 'mount' the necessary stuff.
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.
> 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.
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.)
> determine the PID of the process that you are talking to and use pidfd to validate where it is coming from.
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).
My reasoning behind the pidfd thing would just be as a way to try to avoid race conditions, though on second thought maybe it's not needed. I think you can take your pick on how exactly to validate the executable. My thought was to go (using /proc/.../exe) check that the file is root owned (and in a root owned directory structure) and then use its absolute path as a key. Seems like it would be a decent start that would get you somewhere on any OS.
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.
> 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.
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.
> 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).
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.
> 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.
Because you do not get it: this is not Android. There is no fixed UIDs. There is no fixed absolute paths. The binaries are not always root-owned. There is no central signing authority (thank god!). You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
> You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want.
Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
> hat 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.
I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
I do not see why you'd have your "sandboxes apps" store their private data but then have another storage that is "more secure" for whatever your definition of secure is. You'd just put the data in the "more secure" storage to begin with.
What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
> It would be ill-advised to have each application deal with how to encrypt user data.
Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
> 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.
In which case, my entire remark does not apply and there is some (minor) benefit to a keyring.
> 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.
This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
> 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.
I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
> Because you do not get it: this is not Android. There is no fixed UIDs.
Uhhh... I didn't say anything about fixed UIDs.
> There is no fixed absolute paths.
There is if your distribution says there is.
> The binaries are not always root-owned.
They are if your distribution says they are.
> There is no central signing authority (thank god!).
I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.
But anyway. There is if your distribution has one.
> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
There is if your distribution makes there a way to validate something from the PID.
The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.
Immutable distros exist right now.
> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.
> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".
Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.
> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
sigh
You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.
Checking my kdewallet, I can see the following applications:
- KRDC
- Remmina
- KRDP
- Chromium
- krfb
- xdg-desktop-portal
... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.
Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is being used as a dumb key-value store. One that is encrypted automatically without needing the application to do key management.
> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS (where you get a key value store from the app perspective and do neither cryptography nor key management in the app.)
And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.
> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.
But honestly outside of being a smarmy dickhead (sorry, but I never have any reservations firing back when someone is doing it to me) the point I'm making is that if you want DBus to get fixed instead, well, good for you. I would like a Threadripper for Christmas, while we're at it. Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
(And it really doesn't matter to me what Windows or macOS does here honestly. I care about the Linux desktop, not how it compares to whatever crapware Microsoft and Apple are pushing. They haven't really meaningfully improved the desktop in the past 10 years anyways.)
> There is if your distribution says there is.
You STILL do not get it: This Is Not Android. Even ignoring that most distributions are not going to do what you want them to do (that's the entire point), the distribution has zero power over what users do. Firefox _is_ still distributed as a simple tarball that you can unpack in your home directory and run.
If flatpak or your distribution suddenly start requiring _root_ so that users can run programs that do not really require root, this not only would be a net security degradation rather than improvement, it would prevent me from using that distribution altogether. And yes, these programs need access to the desktop, the theming service, accessibility, input management, etc. for obvious reasons.
This is why even the current method is superior to anything you are proposing here, and the SCM_CREDENTIALS stuff just does not rightly fit in the Linux desktop model.
> I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Ye
ANY that is source based, for example. Actually, I have not used _any_ distribution that would sign even packages in ages, much less binaries.
Go and check how much love you are going to get if you start asking around for people to sign their own binaries to run them in their machine, to implement a sandboxing mechanism that there are a million other, way less intrusive ways to implement.
> The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not.
It doesn't really matter. A user is then going to mount a $HOME through NFS into a serverbox and expect to run graphical applications from there.
> Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
A problem I fully acknowledge. But how would _any_ D-Bus replacement fix that? You'd need to replace _all_ IPC servers to offer some form of "no longer trust the clients" API (more or less what Wayland supposedly did to X11), and this is a decades-long task _at best_. A different IPC system doesn't really help, and may even delay this!.
> Do you know what "principle of least privilege" is? M
Irrelevant when my point is that I want _my_ privileged process to manage the password keyring itself.
> You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data.
The entire raison-d'être for KWallet was to store AND SHARE passwords amongst programs, as a glorified netrc replacement. The "secure" storage part comes later, and few if any people enable the auto-locking mechanism which is the only thing that can offer any sensible protection to it. As you are aware of, KWallet and gnome-keyring have never provided any level of actual secure storage.
> And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
why do you make this distinction for secrets, and not for literally the rest of extremely critical private data that the app store? Why would user want to backup the passwords but not the private app documents?
"You want a private data storage that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap such private data; [other] individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key."
I mean, from your description, you want KWallet to provide protection so that say the mail client cannot access the browser passwords (something I already disagree with). But don't you also want, in this containerized world, for the mail client to NOT be able to read your browser's history, for example? If you already provide secure, containerized storage for apps, I fail to see any specific distinction between "private app data" and "private app secret" (I would still make the distinction if it was "shared"). You'd want your history to be protected (from other programs) as much as any website password.
I do not even know why you bring up the word "regulation" in here.
> What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd
This is not a reading problem: you are still saying that it is a mess because it is a mess. If you want to break the circular reasoning, you have to introduce an actual reason into the loop.
> Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
You keep framing this as if we were not improving the Linux desktop too, which just shows your bias.
My point: Just don't act like it's weird when the actions only result in a LARGER and more explosive trainwreck rather than an improvement.
The funny/sad detail is that the 80s (at the latest) already solved the problem. Have a look as XDR and Sun RPC. It has both strongly typed APIs and versioning built in. You would have to come up with your authentication mechanism for applications e.g. have them send a cookie file (descriptor).
This is the first time I hear that anyone hates D-Bus. I always saw it as a global API Bus that Apps can register to and which enables some sort of interoperability and automation. After all it can even be used from Bash. What is bad about this?
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 architecture is fundamentally broken when you are using multiple window managers / desktop environments https://github.com/dunst-project/dunst/issues/363
> 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.
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.
There's sandbox escapes daily since decades. It doesn't work.
>There's lock picking daily since centuries. It doesn't work
It takes time to pick one lock and twice as much to pick two.
It takes the same time to escape 1 or 10000000 sandboxes.
That's only somewhat true if we are talking about the same sandbox nested (which would be quite dumb to do).
Escaping two different sandboxes are multiple times as hard, and a sane sandbox is not trivially picked, see web browsers and that the fact that the world is not one giant botnet.
How many implementations of linux namespaces are there in the kernel? Is it more than one?
Is a wasm sandbox, or the browser not a sandbox, independent of the kernel?
Check varlink, an alternative to D-Bus defined in the SystemD world.
https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-
Varlink was created independently of systemd. SystemD just adopted it. It just wasn't that well known before that adoption.
Nah, fuck that one in particular. DBus was too type-unsafe? Why not use JSON then, right? Right?!
The reason you do t hear much about it is because it's not an often discussed topic. Nonetheless the hate is there.
Dbus is a godawful mess. Imagine the windows registry, except it can only be inspected at runtime, contains executable binaries and is exceptionally fragile
> 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.
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.
> Does it miss a spec? Write one.
FreeDesktop-dot-Org would not accept one from the author if he did:
https://blog.vaxry.net/articles/2024-fdo-and-redhat
https://blog.vaxry.net/articles/2024-fdo-and-redhat2
I am puzzled by this comment - hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? That's literally what stuff like Flatpak xdg-desktop-portal and Wayland isolation are built around.
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.
> hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox?
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.
I've never had much luck with it either. A lot of the same pain points as the author.
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...
Putting aside the post and whether it's correct or not.
Reinvent what wheel exactly?
D-Bus can't read your mind (yet) and as such it can't generate an API for you, you still need to design a protocol, it's just that it's on top of D-Bus with certain quirks and restrictions.
Doing the same over UDS in 2025 isn't any more work and doesn't have any negative impact on end users. There's nothing unique about D-Bus from a usability standpoint that can't be done with a service listening over UDS.
This is equivalent to saying that you're reinventing the wheel by not using HTTP as a transport.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Maybe you should look at Varlink. The systemd backed D-Bus alternative. It uses JSON.
Regarding secrets management:
My password manager's protocol is handled using exec and command line arguments. Arbitrary applications can ask for passwords, but they won't get them. They won't read them from disk.
The design of the gnome keyring isn't great, but I actually don't think the protocol matters much in this case.
I may be naive, but why not adopt the browsers api development model. 90% shared core apis, experimental ones, for a few years it seems that every group can work on its code without breaking things for user much while new ideas coming regularly.
How does it work exactly? I mean, the premise here is:
"it f*cking works"
Can we objectify this claim made here?
Perhaps the SecretManager deserves some extra attention, but I concur. We worked long enough on this, please dont split whats left of the linux desktop...
> Can't you guys stop reinventing the wheel every other day?
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.
> Do you hate a{sv}? If you propose JSON as alternative,
Obviously, the components should talk using MCP.
You may be joking but I think seriously that may be a decent idea. The universal RPC/automation mechanism which everybody implements-whatever its warts may be-is superior to a better-designed one which few actually end up supporting. You don’t need an LLM to call MCP tools, there’s nothing stopping you from calling MCP tools from any programming language.
I don't recall asking for any "bus" in the first place.
d-bus often fails to work properly, at least on my machine, where systemd is not in use.
it already annoys me.
an alternative would be welcome.
I believe someone from systemd should reimplement d-bus in rust. This way we can have all the things we hate in a single instance.
https://varlink.org/ systemd already has
Problem is, varlink has been created to alleviate the pain while what I'm looking for here is even more suffering. Perhaps add AI and MCP into the mix. At kernel level with hard dependency on sudo-rs. And local RPC should be blockchain-based.
The systemd team mainly writes in (IMHO) horrible C, for one.
But bigger issue is they already tried to push their ideas about d-bus around, and got finally mogged so hard it got canceled.
This is so close to a jwz post that if the stylesheet mimicked his website's, I'd believe it was him.
While there is some valid criticism to be held against D-Bus and its implementations (there's more than one in common use), this article never goes there. It appears to be just an incoherent rambling of someone with poor understanding of how systems work together.
Raises the obvious question of why not using the wayland protocol (on another socket, not on the compositor socket). It has mature implementations in many languages, an IDL with compilers, and every GUI application is already going to link to libwayland anyway.
(Or perhaps even COM)
vaxry has a beef with Drew Devault, who called him out and exposed his behavior when not writing code.
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.
Now that's the info I missed, I knew the hyperland devs have a bad reputation so I was wondering what was not being said , thank you good sir.
Peak FOSS experience
>Back when I was writing xdg-desktop-portal-hyprland, I had to use a few dbus protocols (xdg portals run on dbus) to implement some of the communication. If we go to the portal documentation, we can find the protocols.
>[...]
>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/
> It is not surprising the the properties would not be called the same.
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.
I think this rant is more about Gnome than about dbus. Yes - there's a lot of Worse is better (https://en.wikipedia.org/wiki/Worse_is_better) design in there.
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.
I don't have dbus installed on my linux due to security and privacy concerns. How is this new bus any better?
- Does it allow applications to enumerate what other apps are installed in the system (connected to the bus), without being explicitly allowed by the admin to do that?
- Does it allow apps to talk to each other without being explicitly allowed by the admin?
- Does it allow apps to "publish" data that anyone can read?
- Does it allow apps to "request" actions from other apps running with other privileges than themselves (elevation of privilege)?
D-bus breaks a very basic expectation.
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".
> That when you can open a basic X11 application like xeyes or xterm, you can open any X11 application.
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?
It is not true that X11 is gone. I use it. Many other people use it too.
Can you show where you got the impression that "X11 is gone"?
X11 has been replaced by Wayland as the default on the vast majority of workstations. Servers wouldn't have it anyway.
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.)
I am using OpenBSD on an x86-64 desktop, and X is still very much the supported graphics environment.
That said, there is interest in Wayland in these circles.
https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla...
Supported by whom? Xorg, the server, no longer maintained. Also, OpenBSD users already a tiny fraction of users...if every single OpenBSD desktop switches to Linux and Wayland, not a single metric will change significantly.
OpenBSD also maintains OpenSSH, which has enormous market penetration.
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.
The `-X` and `-Y` options were a mistake to integrate into `ssh(1)`, it makes an assumption that everybody uses an Athena/X11 type system. That said, you can combine waypipe with ssh to do the same thing (ie. `waypipe ssh` will give you the same effect as `ssh -X`).
Until those options are integrated into OpenSSH itself, Wayland remains in the minority.
I'm not sure this statement makes any sense.
> Their ssh supports the -X and -Y options to run remote X applications.
Cool, I remember using it in 2003 a few times. I highly doubt many people going to miss if those were gone. I would not be surprised if the majority of ssh server installations disable x11 session forwarding.
> Until then, get comfortable in a small and discardable minority.
Are you sure you're not confusing Wayland users with OpenBSD users?
OpenBSD maintains its own Xorg fork, called Xenocara.
I mean the discussion is about Linux though no and even if we extend the umbrella with the BSD folks still I don't think wayland drops below %80
I often read the advice that if something does not work on Linux, then switch from Wayland to X11.
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)
X is deprecated. Its maintainers do not want to maintain it. They want you to use Wayland instead.
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.
It's a dead end that allows me to have HiDPI (aka a 4k display) on Ubuntu 24.04 and use the VMWare GUI and OnlyOffice.
Wayland was launched 18 years ago and it still can't handle mainstream apps in common scenarios.
Downvote all you want, I'm telling you what I see. I had to fall back to X...
"I often read the advice that if something does not work on Chrome in the US Govt, try IE6." - This was still true as of last year.
"Trust me, IE6 is not gone" - me
Are there hard numbers to back up the 80% thing? I don't know one way or the other, I'm just skeptical because I still have applications which don't work correctly under Wayland (Discord), and if I have such problems it wouldn't surprise me if others do too.
It's the default for most of the parent/child distros.
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.
> * Arch Linux
Arch doesn't even install a kernel by default, in which possible way does it default to Wayland?
Oops! Sorry I was working in a sheet that had the variants listed and I must have shifted a cell!
Arch clearly doesn't have any "defaults" there. Manjaro is on X11.
SteamOS on Steam Deck does however use Wayland.
The waypipe toole comes quite close to X forwarding on Wayland. :-)
I'm not sure why you would need to have "heard of that". If I was getting Linux to work on my computer as many people have, and got xeyes or xterm to work, I would expect other X11 apps to work as well.
Listen in most discussions bringing up security is a good way for you to shut the conversation down, but in the case of IPC anyone who cares enough will be knowledgeable enough to see it for the red herring it is
It is almost gone for me too, except that I can't adjust brightness on my laptop with Wayland. I can with X11. It's a long story but that's the TL;DR of it. So until all of that almost goes away, it's full X11 at least for some people like me.
I had the same problem until an updated fixed it
There are still many of those kinds of issues left.
I was surprised to learn that Wayland still doesn't offer control of keyboard LEDs like Scroll Lock, so unprivileged programs that use those LEDs cannot be ported to Wayland.
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.
After all they started by locking down everything and then they are creating all the openings that real world programs need to do what people use computers for. It's probably a better approach that starting with everything open and attempting to lock down, but it takes a long time and some of us will be locked out by some hardware / software mismatch. In my case it seems that Noveau can't talk properly with the backlight control of my card. Neither X11 can with those new kernel and driver but at least it can use gamma correction to simulate a darker screen. Wayland does not have gamma correction or it doesn't work as it should, I can't remember.
I don’t think I’ve ever seen a well behaved D-Bus enabled application, NetworkManager being particularly psychotic.
I'm trying a distro with Connman instead of NetworkMangler. It's the same deal. I could not for the life of me get it to connect or even see my cellphone's wifi tethering hotspot.
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.
Are you really thinking of dbus here? It's not in the normal binary loading path. And afterwards, it's not any different from other libraries which may or may not stop the app from functioning for many reasons.
> An important part of adoption will probably be bindings to other languages. The libraries are all in C++, but since they aren't very big (by design), making Rust / Go / Python bindings shouldn't be hard for someone experienced with those languages.
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.
> any app on the bus can read all secrets in the store if the store is unlocked
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?
Funnily enough, my work macOS keychain maimed itself in such a way that I need to recreate it every time I install an OS update. Every time I recreate it, the OS spends a few minutes in a state where every application that needs access to the secrets store requests access through the keychain's password. Incredibly secure!
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.
It's acceptable because flatpak dbus and all its ilk are too opaque for the average "experienced" user to fully grok. The problems are there, but the situation is so convoluted that it's hard to build a mental model unless you truly understand the overall system architecture
keepassxc asks before giving out secrets
Most people disable that.
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.
> This means that when "/usr/bin/firefox" sets a "passwords:superwebsite.com = animebooba", an app called "~/Downloads/totally_legit.sh" can not see ...
It will be interesting to see how it treats symlinks in this case. Or specifically, will this idea break completely for nixos or not.
Keychain ACLs on macOS use the codesigning requirement of the executable requesting the secret.
My guess is it will keep track of the PID
PID changes with every execution. How would it help when preserving configuration data?
Do you mean the real path instead of the PID?
I do not like D-Bus either, and I do not like JSON either. Some of the problems are the ones mentioned there, and it has many other problems as well (one of these is that its use of Unicode can cause problems, but there is a lot more problems than just that). I do not agree with the solutions mentioned there either, although they do make some improvements, there are also some problems.
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.)
Could this bus offer a dbus-compatibility 'firewall/translator' d-bus socket per each app (provided they use the d-bus environment variables correctly)? That might speed adoption if it is able to be a drop-in default, instead of needing to run 2 busses.
One more thing: D-Bus has the concept of generic services which can be automatically started, e.g. org.freedesktop.FileManager1. When you send a command to that service, the file manager will be started if it is not already running. However, there is no mechanism for the user to select which file manager to start, so if you happen to have both KDE and GNOME installed you have a 50:50 chance of launching dolphin or nautilus. See for example: https://unix.stackexchange.com/questions/778028/set-a-specif... . It truly boggles the mind.
D-Bus has no concept of generic services. People are using D-Bus to get automatic startup of generic services even though it's not fit for this purpose. It's quite a different thing.
You could build a viable solution on top of D-Bus though, it's just that apparently nobody bothered so far.
>Back when I was writing xdg-desktop-portal-hyprland
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.
So everyone has wanted "year of the Linux desktop" for a while. This year, since Microsoft has decided to call open season on their own feet and Valve has taken a break from swimming in their money pool to make sure absolutely any piece of software ever written can run on Linux, it looks like this might actually be happening. I am seeing a massive influx of new users, driven by distros like Cachy, Nobara, Bazzite. A lot of them don't have previous Linux experience and are generally not the most technically savvy users.
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.
Any windows program you download can steal all your secrets too. The only operating systems that isolate programs by default are on phones (and chromebooks).
Unless you give it admin permissions, it really can't (admittedly, a lot of Windows users do run their computers with their admin account by default). Also, Windows users generally have at least some kind of anti-malware running, which, while not perfect, does work well against most spray-and-pray malware out there.
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?
All your data is owned by your user. If you run a program, it will have access to all your data. Admin or not is irrelevant here.
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.
I think this is missing the main problem with security on a Linux Desktop, the user. All an attacker has to do is to convince the user to run InstallSteamWithAllGamesUnlockedForFree.sh You know, the AnnaKurnikovaSexTape.exe of the windows world.
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.
nearly everything talks dbus, even browser extensions.
It’s even more serious than running untrusted shell scripts.
That's not the problem. The real problem is that if I convince you to run my script, it's going to be quite easy to convince you to give me extra permissions, so I can get to your data. It really irks me when things like Cargo are doing exactly that, make me run a sh script. Cargo and the likes, are making running sh scripts way too common.
I assume you mean rustup, not cargo specifically or am I wrong?
cargo builds/runs build.rs in the background
Yeah, that was a brain fart.
browser extensions? you mean like Chrome ones etc? never heard of that being a thing
plasma integration and gnome-shell integration do, and those are open source so you can see for yourself.
It’s also very common for password manager extensions like 1password and bitwarden.
Forget running some random downloaded shell script, just needs to convince the user to curl some-url/do-some-cool-thing | bash.
For a second, I thought this was about Deutche Bank's central markets messaging bus, also called D-Bus. So many memories...
I was under the impression that the security concerns there are handled by AppArmor and SELinux (though maybe not granular access control to secrets). Which all desktop Linux installs should be using one or the other, because there's much more than just D-Bus that can be a security risk.
As I understand it, systemctl uses D-Bus to send commands to systemd. I have read that systemd implemented their own D-Bus which is faster than stand-alone D-Bus.
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...
systemd accepts commands from the system bus (i.e. the dbus instance running as uid 0). User desktops have their own session bus, which runs as the user.
Thanks, that makes sense.
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.
polkit
Here's my favourite D-Bus setting when I compile Emacs:
Been using it like this for years, many versions of Emacs and everything Just Works [TM] without D-Bus.DBUS -> Crappy COM
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.
Someone know any technique to watch what sent to the Dbus from running A. I want to then redo and implement my own A. Welcome any steps I can take.
Put OS calls on the bus. IMHO we need to add permissions to most user-space APIs so apps don't need to be sandboxed in a VM for security. Is this what SE Linux is? But I sometimes want permission to be granted by the user. For example, I don't want programs to be able to access files unless the user specifies the file - this might be through direct interaction with a GUI, or if we're really smart/tricky enabled if a filename comes on the command line typed by the user. I hope this makes sense, a way to gate system access via normal user input. Is this a reasonable possibility, or am I dreaming too big?
I think the way to do should be capability-based security. However, that is suitable for a new operating system design (and computer design, too, for some reasons).
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.
This is more or less how a lot of it works on macOS via the “Transparency, Consent, and Control” subsystem. Even non-sandboxed apps cannot just go rooting around my Desktop without the OS throwing a popup up asking me if it’s ok.
I never took d-bus seriously because they said that when dbus was updated you could not just restart the dbus daemon, you were required to hard reboot.
Could not MQTT form the base of a new desktop bus? At least one half of it. It does not specify everything, but would it not be good foundation?
MQTT solves the transport, which really isn't an issue. It solves nothing beyond that.
Sometimes I feel that it would be easy to just take parts of Android instead of reinventing the wheel.
I was bracing for the proposed replacement being integrated in systemd.
which of them? :)
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"
It already has one: Varlink ( https://varlink.org/ ). For pretty much the reasons outlined by the topic starter.
systemd-busdd (pronounced, "busted")
Written in Rust with an MIT license for good measure.
You mean this? https://rust-for-linux.com/android-binder-driver
I wouldn't hate it. I used to hate systemd, but today it's one of my favorite linux things.
It may soon happen. :)
systemd-bus 2.0
> "Everyone has heard about D-Bus"
I have never heard of D-Bus until today.
I sympathize, but also, the XKCD about Standards comes to mind: https://xkcd.com/927/
> A lot of people quote this xkcd comic for each new implementation. However, this is not exactly the same.
Well... It is exactly the same.
> Back when I was writing xdg-desktop-portal-hyprland
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.
> 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!
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.)
I have a very vague familiarity with how it works, but I don't think there are alternatives. If you're using Wayland, you either have to rely on a distro or DE to configure it for you, or do it yourself.
To be fair: I don't think the idea behind portals is necessarily bad. But the half-baked implementations that all do things slightly differently is a pretty bad UX overall.
Hmm, screencasting is finally working properly for me now. It was a loooong road...
Oh, it works for me too, but unless you're using a distro or DE that preconfigures it for you, you have to do it yourself. Which I'm used to on Void Linux and usually don't mind, but it's a horrendous UX that I just didn't have to deal with on X11.
Another one censored title.
[flagged]
We need a protocol, not an implementation, so language is a minor detail nobody should need to care about. It should be easy to use implement by lib developers in various languages, and easy to use for app developers. It should be designed to work on all OSs, even if not all platforms will support it yet.
We may need both actually: solid protocol and great reference implementation.
Wayland was advertised as protocol mostly. After almost 20 years, it still has not promised to be a full replacement to xorg and probably never will, where wayland developers say "this is not our goal". Took people quite some time to realise that; it's been more recently become obvious, but say, 12 years ago few understood this.
I still have not been able to find working replacements to all that works on xorg, for instance; specifically imagemagick is different on wayland. I may try again at a later point in time, but my old workings there did not work, and replacements seem dead or ineffective or incomplete - that is quite frustrating for something that was aggressively advertised as "this is now the future".
100% agree, I should have phrased it less black and white. In theory a spec is all you need but in practice solid reference implementations can iron out ambiguity plus it can uncover issues in the spec.
It's barely a thousand lines of code. What's stopping you from doing it yourself
C++ is memory safe if you use the right compiler
Not everyone wants to recompile the whole app and dependencies with filc to get a slowdown, extra memory use and safety. It's cool that it exists, but omitting the tradeoffs when pushing this is weird.
Nothing weird about it.
Just pointing out the fact that it's not the language that isn't memory safe, it's the implementation you're choosing to use
There is no such thing as a "safe" programming language.
HQ9+
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
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 vocal critic of microsoft but systemd/wayland was one of the best things to happen to linux. If you can improve upon it, then feel free to implement a better solution.
A solution to what? Aside from details of the implementation, one can also disagree with the framing of the problem and scope of the solution. Sure, we're free to implement an alternative solution for doing DNS resolution and IPC and logging and time synchronization and job scheduling and service monitoring and ... but should there be a single solution to all of these things at once?
All of the things you mention are interdependent, as resource and service management is the core of it all. I'm convinced that they set out to design somethign that has a scope which is as small as possible, but then noticed that interfacing with legacy-but-established open source software was extremely difficult.
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.
It's literally not a single solution. systemd isn't a piece of software, it's, like, 20 pieces of software.
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.
Right, I guess I shouldn't have edited out my preemptive response to this: Of course the solution is internally composed of different parts. Most things are. People of course understand that those internal parts could be switched out for new parts that perform the same role in the overall solution, but that doesn't help when the disagreement is about the scope and purpose of the entire solution.
Right, what I'm saying is there IS no entire solution. It's just project naming conventions.
Like, systemd-boot has literally nothing to do with systemd. Nothing at all. It just uses the project name. Which is confusing, sure.
Who said anything about an init system?
When people talk about systemd being a big ole monolith against the unix philosophy this is usually what they mean. And it's just not true. Like, theres no argument to be had because systemd is many pieces of software that do one thing.
We're not talking about "when people usually", we're in this subthread and you're the only person talking about init here.
My point was there is no systemd software. Systemd is a project naming convention with many projects under its umbrella that do not rely on each other in any way.
It's sort of like saying KDE is a whole thing because it has a text editor. Uh, no - KDE is a project, Kate is a text editor part of the k applications suite, which has nothing to do with plasma, the desktop shell. You can use Kate on any shell. You can use plasma without Kate.
Wherever they might be working now.. isn't really relevant to the project
> 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]
https://en.wikipedia.org/wiki/Systemd#History
> Lennart Poettering and Kay Sievers, the software engineers then working for Red Hat who initially developed systemd
This is wrong, Kay Sievers was working for Novell/SuSE at that time, see https://0pointer.de/blog/projects/systemd.html#faqs
A note about this conversation. and your improvements has been added to the "talk" page - Can I recommend that you make the appropriate change to the actual page?
(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)
Thanks for adding a note, but I can't edit Wikipedia as I do not have an account. Let's hope it will be noticed.