• ulterno@programming.devEnglish
    4·
    5 hours ago

    vaxry talked about LD_PRELOAD and I feel like that is a non-issue in this case.
    If an attacker has the ability to modify LD_PRELOAD of an application, they already an ability to modify its behaviour without depending upon what D-Bus may let it do.
    And if the attacker can change LD_PRELOAD for a process running as root, they might as well affect the target service directly rather than try doing something with the dbus daemon.

  • realitaetsverlust@piefed.zipEnglish
    221·
    19 hours ago

    Honestly 80% of the article is ranting about developer not writing proper documentation or following specs which is not the fault of D-Bus. The only point that I agree with is the lack of security features, but that has never really been a thing back then. Half of the shit that was developed was completely insecure. Not saying that’s a good thing btw. But that can be fixed.

    • jrgd@lemmy.zipEnglish
      8·
      15 hours ago

      To be fair, D-Bus is a protocol. Proper documentation and standards is half of implementation. Without any well-defined standards, a protocol is essentially useless and/or lawless. While not every case of non-compliance is the fault of D-Bus, the general lax nature of how endpoints are intended to be defined as well as the incompleteness for the actual standards applications should adhere to is a significant factor for why many applications are the way they are. In addition to the severe security flaws in D-Bus, this could be written with extensions to the protocol, becoming a new standard. Though if the problems are as deeply rooted as they are, it’s not entirely out of the question to create another standard that isn’t D-Bus.

      • realitaetsverlust@piefed.zipEnglish
        3·
        11 hours ago

        So, first of all, I barely ever had to work with d-bus directly - I used it a few times and it was fine to use.

        Without any well-defined standards, a protocol is essentially useless and/or lawless

        When I look for “D-Bus Specification”, I get this: https://dbus.freedesktop.org/doc/dbus-specification.html. This LOOKS like a proper documentation of the standard to me.

        the general lax nature of how endpoints are intended to be defined … is a significant factor for why many applications are the way they are

        I feel like this is the same complaint people have about other things, like PHP for example. They see shitty PHP code (like wordpress) and are like: “Oh my god PHP is such a shitty language because this application is written like shit”. But I don’t blame a language, a framework or a protocol for the failures of the users. I don’t feel like an application that close to the system core has to be absolutely “dummy proof”. At some point, we should just expect that people know what they’re doing, and if they don’t, we should blame them, not the underlying technology.

      • ulterno@programming.devEnglish
        0·
        6 hours ago

        severe security flaws in D-Bus

        I searched for this and all I got was CVEs in the implementations.
        What are the flaws in the protocol that I don’t know of? If you can link it, I would love to read.

        I recently started interacting with code that had something to do with D-Bus and from what I saw, there were policy files, which are required to do anything with D-Bus endpoints provided by software. That’s essentially where I stopped, considering that to be the end-all for D-Bus security.

        What am I missing?

  • LiveLM@lemmy.zipEnglish
    3·
    14 hours ago

    With each passing day Vaxry seems closer and closer to re-implementing the entire userland, I don’t know how he avoids burning out…

  • mmmm@sopuli.xyz
    12·
    20 hours ago

    I agree with some comments at HN about that proposing an alternative is kinda pointless. D-Bus, contrary to the X situation, can be fixed.

  • Deebster@infosec.pub
    9·
    20 hours ago

    This is quite interesting. I’d been looking into dbus lately and was confused by a few design choices so it makes sense to me that the design is faulty.

    Running both simultaneously seems pretty feasible since the session bus bus should be quite lightweight (worse case would be a lot of inter-bus traffic if/when that gets implemented).

    Security and kv are excellent features.

    I feel it might have more luck gaining adoption if its name did t tie it to hyprland.

  • Samueru_sama@programming.devEnglish
    2·
    17 hours ago

    Portals could have been much simpler like how xdg-open works.

    I’m surprised it seems nobody has tried to write an alternative to portals that doesn’t use dbus?