13 ms·

Problems with D-Bus on the Linux desktop

336 points by LorenDB 10mo ago

jzer0cool 10mo ago
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.
ginko 10mo ago
I was bracing for the proposed replacement being integrated in systemd.
- riskable 10mo ago
  systemd-busdd (pronounced, "busted")
- 112233 10mo ago
  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"
- shevy-java 10mo ago
  It may soon happen. :) systemd-bus 2.0
- cyberax 10mo ago
  It already has one: Varlink ( https://varlink.org/ https://varlink.org/ ). For pretty much the reasons outlined by the topic starter.
- Narishma 10mo ago
  Written in Rust with an MIT license for good measure.
  - 0x457 10mo ago
    You mean this? https://rust-for-linux.com/android-binder-driver https://rust-for-linux.com/android-binder-driver
- 0x457 10mo ago
  I wouldn't hate it. I used to hate systemd, but today it's one of my favorite linux things.
smokel 10mo ago
[flagged]
- monster_truck 10mo ago
  It's barely a thousand lines of code. What's stopping you from doing it yourself
- otabdeveloper4 10mo ago
  There is no such thing as a "safe" programming language.
  - Y_Y 10mo ago
    HQ9+
- klabb3 10mo ago
  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.
  - shevy-java 10mo ago
    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".
jasonjayr 10mo ago
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.
charcircuit 10mo ago
>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.
- zb3 10mo ago
  Binder will come to linux desktop soon... together with Android :)
  - anon-3988 10mo ago
    Is there any plans by some DE to replace D-bus with Binder?
- bee_rider 10mo ago
  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…
  - schmichael 10mo ago
    https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder...
  - charcircuit 10mo ago
    Binder is the primary way apps talk to the various OS services on Android. https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder... https://www.kernel.org/doc/html/latest/admin-guide/binderfs.html https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
    - pjmlp 10mo ago
_flux 10mo ago
From the style of this article I expected that https://github.com/hyprwm/hyprwire https://github.com/hyprwm/hyprwire and https://github.com/hyprwm/hyprtavern 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.
- Oxodao 10mo ago
  tbf they stated in their article that those are not there YET multiple time. We'll wait and see once they're done
- wpm 10mo ago
  I believe the sole author is doing finals for their last year of university at the moment.
publicdebates 10mo ago
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?
- supportengineer 10mo ago
  There is definitely an elite cabal with its thumb on the scale here.
  - baobun 10mo ago
    And the prevalance of D-Bus is part of it...? Spill the beans!
  - sph 10mo ago
    The deep state forcing everybody to use GNOME smh my head
- Y_Y 10mo ago
  Worse is better, but meta, because the worst way of choosing is what wins
- bigfatkitten 10mo ago
  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.
  - Conan_Kudo 10mo ago
    No, it remained relevant because Ubuntu based every stack for their desktop on GNOME technologies (except the aborted Unity 8).
AshamedCaptain 10mo ago
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.
- shevy-java 10mo ago
  How does it work exactly? I mean, the premise here is: "it f*cking works" Can we objectify this claim made here?
- antiloper 10mo ago
  > 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 https://wayland.app/protocols/xdg-shell Etc. etc. This isn't the 90s anymore.
amelius 10mo ago
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".
- csdreamer7 10mo ago
  > 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?
  - ambicapter 10mo ago
    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.
  - shevy-java 10mo ago
    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"?
    - esseph 10mo ago
      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.)
      - amelius 10mo ago
        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)
shevy-java 10mo ago
> 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.
- awesome_dude 10mo ago
  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 https://en.wikipedia.org/wiki/Systemd#History
  - the_why_of_y 10mo ago
    > 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 https://0pointer.de/blog/projects/systemd.html#faqs
    - awesome_dude 10mo ago
      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)
      - the_why_of_y 10mo ago
        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.
debo_ 10mo ago
This is so close to a jwz post that if the stylesheet mimicked his website's, I'd believe it was him.
Terr_ 10mo ago
> 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.
- XorNot 10mo ago
  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.
  - jeroenhd 10mo ago
    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.
    - XorNot 10mo ago
      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.
senko 10mo ago
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.
- GalaxyNova 10mo ago
  > 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.
  - senko 10mo ago
    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.
  - forty 10mo ago
    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.
- Asooka 10mo ago
TuringNYC 10mo ago
For a second, I thought this was about Deutche Bank's central markets messaging bus, also called D-Bus. So many memories...
antiloper 10mo ago
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)
- bayindirh 10mo ago
  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.
  - grimblee 10mo ago
    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.
  - wolvesechoes 10mo ago
    Peak FOSS experience
bflesch 10mo ago
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 :-)
- anthk 10mo ago
  Not an issue with a standalone VM :D
  - dijit 10mo ago
    Now you have two problems.
    - anthk 10mo ago
      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.
- psanford 10mo ago
  What browser extensions? Why would I want websites to integrate with gnome or kde? What does that even mean?
  - airhangerf15 10mo ago
    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).
    - psanford 10mo ago
GalaxyNova 10mo ago
> 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?
- throw_await 10mo ago
  keepassxc asks before giving out secrets
  - XorNot 10mo ago
    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.
- jeroenhd 10mo ago
  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.
- mx7zysuj4xew 10mo ago
supportengineer 10mo ago
> "Everyone has heard about D-Bus" I have never heard of D-Bus until today.
pjmlp 10mo ago
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.
- GalaxyNova 10mo ago
  The fragmentation is a natural consequence of different use cases existing. You can't have your cake and eat it too.
  - pjmlp 10mo ago
    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.
    - danans 10mo ago
      > ChromeOS commonality is the Linux kernel, not userspace. ChromeOS has a Linux userspace fully integrated via it's Crostini VM.
      - pjmlp 10mo ago
        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.
        danans 10mo ago
        > 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.
viraptor 10mo ago
> 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.
- GalaxyNova 10mo ago
  My guess is it will keep track of the PID
  - viraptor 10mo ago
    PID changes with every execution. How would it help when preserving configuration data?
  - tmtvl 10mo ago
    Do you mean the real path instead of the PID?
- wpm 10mo ago
  Keychain ACLs on macOS use the codesigning requirement of the executable requesting the secret.
anthk 10mo ago
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.
BeetleB 10mo ago
> 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.
- deleted 10mo ago
  [deleted]
- Gualdrapo 10mo ago
  I don't think they implied that old software is always bad.
- yxhuvud 10mo ago
  Plenty of the implementation not so much, however.
mongol 10mo ago
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?
- 0x457 10mo ago
  MQTT solves the transport, which really isn't an issue. It solves nothing beyond that.
zzo38computer 10mo ago
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.)
peanut-walrus 10mo ago
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.
- Dylan16807 10mo ago
  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).
  - peanut-walrus 10mo ago
    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?
mahkoh 10mo ago
>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.freedesktop.portal.ScreenCast.html#org-freedesktop-portal-screencast-selectsources https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... [2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.ScreenCast.html#org-freedesktop-impl-portal-screencast-selectsources https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... [3]: https://flatpak.github.io/xdg-desktop-portal/docs/ https://flatpak.github.io/xdg-desktop-portal/docs/
- Sprocklem 10mo ago
  > 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.
phkahler 10mo ago
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?
- wpm 10mo ago
  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.
- zzo38computer 10mo ago
  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.
egorfine 10mo ago
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.
- klooney 10mo ago
  https://varlink.org/ https://varlink.org/ systemd already has
  - egorfine 10mo ago
    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.
- p_l 10mo ago
  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.
0manrho 10mo ago
I sympathize, but also, the XKCD about Standards comes to mind: https://xkcd.com/927/ https://xkcd.com/927/
- bsoles 10mo ago
  > 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.
wryun 10mo ago
OpenWrt devs had this epiphany many years ago: https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus#what_s_the_difference_between_ubus_vs_dbus 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)
chasil 10mo ago
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_busctl_as_dbus_clients_visual_guide/?rdt=57789 https://www.reddit.com/r/linux/comments/1lxd0hl/systemctl_vs...
- tremon 10mo ago
  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.
  - chasil 10mo ago
    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.
- zokier 10mo ago
  polkit
1718627440 10mo ago
> 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=31283 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?
- ottah 10mo ago
  Wayland, thow shall not screenshot without root. D-Bus, YOLo!
  - 1718627440 10mo ago
    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.
    - seba_dos1 10mo ago
      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.
imiric 10mo ago
> 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 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.
- javier2 10mo ago
  Hmm, screencasting is finally working properly for me now. It was a loooong road...
  - imiric 10mo ago
    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.
ghusto 10mo ago
> 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.
- Asooka 10mo ago
  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
- tocariimaa 10mo ago
  "works as intended wontfix conversation locked"
- skydhash 10mo ago
  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.
  - k4rnaj1k 10mo ago
    [dead]
  - WD-42 10mo ago
    That’s exactly what it’s for. Parent is just being rude for no reason.
  - rnhmjoj 10mo ago
    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 https://docs.kernel.org/security/keys/core.html
deleted 10mo ago
[deleted]
pbalau 10mo ago
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.
- dijit 10mo ago
  nearly everything talks dbus, even browser extensions. It’s even more serious than running untrusted shell scripts.
  - r_lee 10mo ago
    browser extensions? you mean like Chrome ones etc? never heard of that being a thing
    - dijit 10mo ago
      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.
  - pbalau 10mo ago
    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.
    - juliangmp 10mo ago
      I assume you mean rustup, not cargo specifically or am I wrong?
smetannik 10mo ago
Sometimes I feel that it would be easy to just take parts of Android instead of reinventing the wheel.
candide771 10mo ago
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 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.
dolmen 10mo ago
> 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.
Asooka 10mo ago
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-specific-file-manager-for-org-freedesktop-filemanager1-showitems https://unix.stackexchange.com/questions/778028/set-a-specif... . It truly boggles the mind.
- seba_dos1 10mo ago
  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.
seba_dos1 10mo ago
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.
TacticalCoder 10mo ago
Here's my favourite D-Bus setting when I compile Emacs: --without-dbus Been using it like this for years, many versions of Emacs and everything Just Works [TM] without D-Bus.
throw7 10mo ago
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.
notnullorvoid 10mo ago
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.
jauntywundrkind 10mo ago
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.
moggers123 10mo ago
>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.
rendaw 10mo ago
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.
wltr 10mo ago
Another one censored title.
M95D 10mo ago
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)?

336 points by LorenDB 10mo ago

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.

ginko 10mo ago

I was bracing for the proposed replacement being integrated in systemd.

riskable 10mo ago
systemd-busdd (pronounced, "busted")
112233 10mo ago
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"
shevy-java 10mo ago
It may soon happen. :) systemd-bus 2.0
cyberax 10mo ago
It already has one: Varlink ( https://varlink.org/ https://varlink.org/ ). For pretty much the reasons outlined by the topic starter.
Narishma 10mo ago
Written in Rust with an MIT license for good measure.
- 0x457 10mo ago
  You mean this? https://rust-for-linux.com/android-binder-driver https://rust-for-linux.com/android-binder-driver
0x457 10mo ago
I wouldn't hate it. I used to hate systemd, but today it's one of my favorite linux things.

smokel 10mo ago

[flagged]

monster_truck 10mo ago
It's barely a thousand lines of code. What's stopping you from doing it yourself
otabdeveloper4 10mo ago
There is no such thing as a "safe" programming language.
- Y_Y 10mo ago
  HQ9+
klabb3 10mo ago
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.
- shevy-java 10mo ago
  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".

jasonjayr 10mo ago

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.

charcircuit 10mo ago

>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.

zb3 10mo ago
Binder will come to linux desktop soon... together with Android :)
- anon-3988 10mo ago
  Is there any plans by some DE to replace D-bus with Binder?
bee_rider 10mo ago
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…
- schmichael 10mo ago
  https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder...
- charcircuit 10mo ago
  Binder is the primary way apps talk to the various OS services on Android. https://source.android.com/docs/core/architecture/ipc/binder-overview https://source.android.com/docs/core/architecture/ipc/binder... https://www.kernel.org/doc/html/latest/admin-guide/binderfs.html https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
  - pjmlp 10mo ago

_flux 10mo ago

From the style of this article I expected that https://github.com/hyprwm/hyprwire https://github.com/hyprwm/hyprwire and https://github.com/hyprwm/hyprtavern 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.

Oxodao 10mo ago
tbf they stated in their article that those are not there YET multiple time. We'll wait and see once they're done
wpm 10mo ago
I believe the sole author is doing finals for their last year of university at the moment.

publicdebates 10mo ago

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?

supportengineer 10mo ago
There is definitely an elite cabal with its thumb on the scale here.
- baobun 10mo ago
  And the prevalance of D-Bus is part of it...? Spill the beans!
- sph 10mo ago
  The deep state forcing everybody to use GNOME smh my head
Y_Y 10mo ago
Worse is better, but meta, because the worst way of choosing is what wins
bigfatkitten 10mo ago
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.
- Conan_Kudo 10mo ago
  No, it remained relevant because Ubuntu based every stack for their desktop on GNOME technologies (except the aborted Unity 8).

AshamedCaptain 10mo ago

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.

shevy-java 10mo ago
How does it work exactly? I mean, the premise here is: "it f*cking works" Can we objectify this claim made here?
antiloper 10mo ago
> 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 https://wayland.app/protocols/xdg-shell Etc. etc. This isn't the 90s anymore.

amelius 10mo ago

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".

csdreamer7 10mo ago
> 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?
- ambicapter 10mo ago
  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.
- shevy-java 10mo ago
  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"?
  - esseph 10mo ago
    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.)
    - amelius 10mo ago
      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)

shevy-java 10mo ago

> 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.

awesome_dude 10mo ago
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 https://en.wikipedia.org/wiki/Systemd#History
- the_why_of_y 10mo ago
  > 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 https://0pointer.de/blog/projects/systemd.html#faqs
  - awesome_dude 10mo ago
    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)
    - the_why_of_y 10mo ago
      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.

debo_ 10mo ago

This is so close to a jwz post that if the stylesheet mimicked his website's, I'd believe it was him.

Terr_ 10mo ago

> 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.

XorNot 10mo ago
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.
- jeroenhd 10mo ago
  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.
  - XorNot 10mo ago
    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.

senko 10mo ago

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.

GalaxyNova 10mo ago
> 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.
- senko 10mo ago
  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.
- forty 10mo ago
  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.
Asooka 10mo ago

TuringNYC 10mo ago

For a second, I thought this was about Deutche Bank's central markets messaging bus, also called D-Bus. So many memories...

antiloper 10mo ago

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)

bayindirh 10mo ago
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.
- grimblee 10mo ago
  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.
- wolvesechoes 10mo ago
  Peak FOSS experience

bflesch 10mo ago

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 :-)

anthk 10mo ago
Not an issue with a standalone VM :D
- dijit 10mo ago
  Now you have two problems.
  - anthk 10mo ago
    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.
psanford 10mo ago
What browser extensions? Why would I want websites to integrate with gnome or kde? What does that even mean?
- airhangerf15 10mo ago
  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).
  - psanford 10mo ago

GalaxyNova 10mo ago

> 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?

throw_await 10mo ago
keepassxc asks before giving out secrets
- XorNot 10mo ago
  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.
jeroenhd 10mo ago
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.
mx7zysuj4xew 10mo ago

supportengineer 10mo ago

> "Everyone has heard about D-Bus" I have never heard of D-Bus until today.

pjmlp 10mo ago

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.

GalaxyNova 10mo ago
The fragmentation is a natural consequence of different use cases existing. You can't have your cake and eat it too.
- pjmlp 10mo ago
  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.
  - danans 10mo ago
    > ChromeOS commonality is the Linux kernel, not userspace. ChromeOS has a Linux userspace fully integrated via it's Crostini VM.
    - pjmlp 10mo ago
      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.
      - danans 10mo ago
        > 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.

viraptor 10mo ago

> 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.

GalaxyNova 10mo ago
My guess is it will keep track of the PID
- viraptor 10mo ago
  PID changes with every execution. How would it help when preserving configuration data?
- tmtvl 10mo ago
  Do you mean the real path instead of the PID?
wpm 10mo ago
Keychain ACLs on macOS use the codesigning requirement of the executable requesting the secret.

anthk 10mo ago

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.

BeetleB 10mo ago

> 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.

deleted 10mo ago
[deleted]
Gualdrapo 10mo ago
I don't think they implied that old software is always bad.
yxhuvud 10mo ago
Plenty of the implementation not so much, however.

mongol 10mo ago

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?

0x457 10mo ago
MQTT solves the transport, which really isn't an issue. It solves nothing beyond that.

zzo38computer 10mo ago

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.)

peanut-walrus 10mo ago

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.

Dylan16807 10mo ago
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).
- peanut-walrus 10mo ago
  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?

mahkoh 10mo ago

>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.freedesktop.portal.ScreenCast.html#org-freedesktop-portal-screencast-selectsources https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... [2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.ScreenCast.html#org-freedesktop-impl-portal-screencast-selectsources https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... [3]: https://flatpak.github.io/xdg-desktop-portal/docs/ https://flatpak.github.io/xdg-desktop-portal/docs/

Sprocklem 10mo ago
> 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.

phkahler 10mo ago

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?

wpm 10mo ago
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.
zzo38computer 10mo ago
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.

egorfine 10mo ago

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.

klooney 10mo ago
https://varlink.org/ https://varlink.org/ systemd already has
- egorfine 10mo ago
  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.
p_l 10mo ago
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.

0manrho 10mo ago

I sympathize, but also, the XKCD about Standards comes to mind: https://xkcd.com/927/ https://xkcd.com/927/

bsoles 10mo ago
> 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.

wryun 10mo ago

OpenWrt devs had this epiphany many years ago: https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus#what_s_the_difference_between_ubus_vs_dbus 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)

chasil 10mo ago

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_busctl_as_dbus_clients_visual_guide/?rdt=57789 https://www.reddit.com/r/linux/comments/1lxd0hl/systemctl_vs...

tremon 10mo ago
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.
- chasil 10mo ago
  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.
zokier 10mo ago
polkit

1718627440 10mo ago

> 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=31283 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?

ottah 10mo ago
Wayland, thow shall not screenshot without root. D-Bus, YOLo!
- 1718627440 10mo ago
  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.
  - seba_dos1 10mo ago
    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.

imiric 10mo ago

> 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 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.

javier2 10mo ago
Hmm, screencasting is finally working properly for me now. It was a loooong road...
- imiric 10mo ago
  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.

ghusto 10mo ago

> 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.

Asooka 10mo ago
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
tocariimaa 10mo ago
"works as intended wontfix conversation locked"
skydhash 10mo ago
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.
- k4rnaj1k 10mo ago
  [dead]
- WD-42 10mo ago
  That’s exactly what it’s for. Parent is just being rude for no reason.
- rnhmjoj 10mo ago
  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 https://docs.kernel.org/security/keys/core.html

deleted 10mo ago

[deleted]

pbalau 10mo ago

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.

dijit 10mo ago
nearly everything talks dbus, even browser extensions. It’s even more serious than running untrusted shell scripts.
- r_lee 10mo ago
  browser extensions? you mean like Chrome ones etc? never heard of that being a thing
  - dijit 10mo ago
    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.
- pbalau 10mo ago
  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.
  - juliangmp 10mo ago
    I assume you mean rustup, not cargo specifically or am I wrong?

smetannik 10mo ago

Sometimes I feel that it would be easy to just take parts of Android instead of reinventing the wheel.

candide771 10mo ago

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 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.

dolmen 10mo ago

> 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.

Asooka 10mo ago

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-specific-file-manager-for-org-freedesktop-filemanager1-showitems https://unix.stackexchange.com/questions/778028/set-a-specif... . It truly boggles the mind.

seba_dos1 10mo ago
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.

seba_dos1 10mo ago

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.

TacticalCoder 10mo ago

Here's my favourite D-Bus setting when I compile Emacs: --without-dbus Been using it like this for years, many versions of Emacs and everything Just Works [TM] without D-Bus.

throw7 10mo ago

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.

notnullorvoid 10mo ago

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.

jauntywundrkind 10mo ago

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.

moggers123 10mo ago

>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.

rendaw 10mo ago

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.

wltr 10mo ago

Another one censored title.

M95D 10mo ago

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)?