• @[email protected]
    link
    fedilink
    562 months ago

    This will probably lead to vocal outrage because it’s Systemd rather than an alternative project coming up with the solution.

    Sudo has long known to have dangerous weaknesses, but it’s generally been accepted since sudo solves a bunch of other problems. If we can fix the problems sudo has, then that’s a good thing. Would be nicer if we could split up some of these projects though to stop uber projects.

    • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍
      link
      fedilink
      20
      edit-2
      2 months ago

      The outrage is that the solution is to suck the feature into an already massive project built to replace initd and has absorbed several other services (syslog, logind, crond), creating dependencies along the way.

      systemd will be superceded, like pulseaudio, because it has an awful design. It’ll just be a lot more work for distros to replace because of all the other services it’s absorbed. Hopefully by then Poettering will have retired and stopped inflicting his software in people. The problem isn’t his initial offerings; those are rather good and solve a problem well. Good enough that distros adopt it. It’s just that he can’t resist feature envy and bloat, and once a distro has a dependency on his solution, the bloat comes along and it’s more work to switch away than just let the bloat take over.

      Edit: “superseded?” Where were you when I needed you, autocorrect?

      • @FizzyOrange
        link
        222 months ago

        The reason systemd absorbs other services is because it’s trying to make a proper integrated OS userland. Having a load of separate components that don’t really know anything about each other kiiind of works, but it’s super janky.

        For example Windows has supported a secure attention key sequence (ctrl-alt-del) for literal decades. Linux still doesn’t support this very basic - and critical for shared computing environments like schools - feature, because it requires coordinating X11 and logind and the kernel and god knows what else and they simply aren’t properly integrated.

        The systemd hatred strongly reminds me of when Xorg started automating the config and you no longer needed xfree86config. You didn’t need to manually write mode lines and tell X that your mouse had 3 buttons, and some people did not like that.

        Yes it sounds completely insane that people wouldn’t like this obvious improvement where things used to require tedious manual configuration and now they worked automatically but some people really didn’t I promise! My theory is that it’s because a) it made their hard won knowledge obsolete, making them less smart relatively, and b) they resented the fact that they had to go through the pain but new people wouldn’t and that isn’t fair.

        Seems similar with systemd. I would like my laptop to sleep properly please.

        Also I have actually read some of the sudo source code. There’s absolutely no way that code should be SUID. Insane.

      • @[email protected]
        link
        fedilink
        7
        edit-2
        2 months ago

        Yep, completely agree. That was essentially the last line of my comment.

        I also wish that journald had a spec for its database, or standardised on something like Sqlite which could be interrogated with generic tooling.

        • Agree, and I think I understood what you meant.

          I can see an argument that Poettering is a net good because he does something, and it’s usually pretty decent to start. Then after it’s been widely adopted, some weird software megalomania takes over and it swells into a bloated carcass until someone is motivated enough to build a better, more focused, replacement.

          systemd is a distro builder’s dream: all you need is that and a kernel, and you’ve got most of the non-userspace, so you throw GNU on top and you’re free to do what you really wanted to focus on: a new package manager, or a specific desktop environment, bells-and-whistles.

          I really hate journald. Like, with enough passion I’m slowly converting all my systems away from systemd, just to get rid of it. It’s slow and buggy, and the fact that I can’t swap it out for something else is the reason I’m anti-systemd. Which is an excellent initd replacement, IMO, and if that were all it was I’d be a fan-boi. But journald stinks, for all the reasons you point out, and more.

      • @[email protected]
        link
        fedilink
        22 months ago

        Hopefully by then Poettering will have retired and stopped inflicting his software in people.

        How did he get so much influence over most mainstream distros? Asking for a friend…

          • @[email protected]
            link
            fedilink
            22 months ago

            No, that’s too rational. What leverage does he have on all of these distro maintainers? Someone needs to get to the bottom of this! /s

            • @[email protected]
              link
              fedilink
              22 months ago

              As far as I remember Poettering worked for IBM’s RedHat for some time and then the systemd lobbying vibe became stronger (with Fedora being the RedHat toy). Nowadays Poettering works for Microsoft, btw.

              lmao found one answer exactly like that

        • Because the software he writes starts out good, and solves problems. systemd is a really nice initd replacement. Pulseaudio really improved audio on Linux. Distros adopted them because they were good.

          The problem is feature creep, exactly like the OP post. For some reason, Poettering’s projects can’t contain themselves to a problem space. Converting init systems is a lot of work, and even if Debian had recognized the feature-creep of systemd as undesirable, there was no way they were going through all of the pain and suffering of another migration. Plus, there isn’t yet a clear successor to systemd. My money is on dinit; s6 is simply too complex, and has too many commands to remember. But the point is, systemd was an excellent initd replacement, and there was a lot of adoption when that’s all it was. And as it grew, distros were already committed and stuck with it (although, journald was there from the beginning, and that should have sounded warning bells).

        • lemmyreader
          link
          fedilink
          English
          32 months ago

          As far as I remember Poettering worked for IBM’s RedHat for some time and then the systemd lobbying vibe became stronger (with Fedora being the RedHat toy). Nowadays Poettering works for Microsoft, btw.

    • @[email protected]
      link
      fedilink
      122 months ago

      mesa and linux is also “uber projects” i think in certains canes you can’t run away from them, systemd is the same, but for privilegiated processes that need to be well integrated for security reasons

      • @[email protected]
        link
        fedilink
        142 months ago

        While I agree that sometimes Uber projects happen, for efficiency or security reasons, I don’t think that Mesa is a good example as they have a scope (implement the OpenGL/Vulkan API) and stick to it.

        Systemd is already confusing because of it referencing two different projects, and the overarching systemd projects scope just increases on a regular basis without what appears to external observers as a plan.

        • @[email protected]
          link
          fedilink
          English
          72 months ago

          Is journald still binary? That alone made me turn away. I am using PCLinuxOS hence am systemd free. Stopped reading up on it.

          • lemmyreader
            link
            fedilink
            English
            7
            edit-2
            2 months ago

            Is journald still binary? That alone made me turn away.

            Yes, unreadable with a text editor. Meaning that if you have a computer problem and journald or systemd is broken you have can’t consult the log files, unless you did install rsyslog or sometimes before that. Meanwhile by default journald will eat a few GBs of disk space soon.

            • @[email protected]
              link
              fedilink
              English
              22 months ago

              Compared to this what is the advantage of binary form? I thought log files being text was a no brainer.

              • @[email protected]
                link
                fedilink
                72 months ago

                Storage efficiency, faster queries, more metadata, unified format, etc. If your host breaks, you can download the journals and open then elsewhere. Also, there is nothing stopping you from configuring it to output to a file.

          • @[email protected]
            link
            fedilink
            -22 months ago

            “on nooo i’m gonna stop using what make modern linux OS good just because they save logs in binary, istead of binary w ith .txt 😭😭” go ahead them, make your life worse

            • lemmyreader
              link
              fedilink
              English
              4
              edit-2
              2 months ago

              “on nooo i’m gonna stop using what make modern linux OS good just because they save logs in binary, istead of binary w ith .txt 😭😭” go ahead them, make your life worse

              😒

              One can keep on using systemd and complain about journald and install rsyslogd and then you’d have the journalctl -f command to impress your Linux noob friends ;-) and /var/log/syslog when there’s trouble when journald would be dead.

              • @[email protected]
                link
                fedilink
                12 months ago

                if you can’t access journald you have a bigger problem than crying about it’s binary file format, but ok keep needing to parse every fucking log using grep and taking 30 second to find anything meaningful if you hate yourself that much

    • @[email protected]
      link
      fedilink
      11 month ago

      I just want Sudo registered to a hardware key. No sudo for you unless you plug in your key.

      Let’s get back to the old hacker movies where burglary was involved.

          • @refalo
            link
            22 months ago

            deleted by creator

          • @Lmaydev
            link
            02 months ago

            Not all jokes are sarcasm.

            Sarcasm involves saying the opposite of what you mean, which can be hard to detect in text form as tone is usually used to express it.

            • Rustmilian
              link
              fedilink
              English
              3
              edit-2
              2 months ago

              He’s literally using sarcasm to mock the idea of fully switching from GNU/Linux to SystemD/Linux. The “/s” at the end indicates the statement is sarcastic, meaning he does not actually believe this switch will happen, but is sarcastically suggesting it will.

              Literally just say out loud to yourself with a sarcastic tone :

              So when are we going to fully switch from GNU/Linux to SystemD/Linux?

              He’s not literally asking when this switch will occur, but rather mocking the notion in a sarcastic tone. Sarcasm involves using words in a mocking or ironic way, often to criticize or make a humorous point, rather than stating the opposite of what one means in a literal sense as a rule of thumb, the sarcastic tone is the key. The implied meaning is the opposite of the implied statement within the sarcastic question, rather than stating the opposite directly. I believe you’re confused because he’s framing it as a question to obfuscate the meaning and make the sarcasm more subtle.

  • @FizzyOrange
    link
    182 months ago

    This sounds like a great improvement. I have read the sudo source code and anyone that seriously thinks there’s no problem with it being SUID is crazy.

    That said the whole security model of sudo makes no sense. As soon as you can access a sudoers’ account you can trivially steal their password by MitMing sudo and waiting.

    • @[email protected]
      link
      fedilink
      12 months ago

      the whole security model of sudo makes no sense

      I think that is a bit strong. Sure, you aren’t gaining much protection if you just allow sudo -su root but there are a lot of valid use cases.

      1. Logging.
      2. A bit of an “explicit” check to keep you from doing something stupid without thinking.
      3. You can configure sudo to only allow specific commands from different users. (Maybe a trusted friend should have permission to reboot your Minecraft server but nothing else)
  • @mikyopii
    link
    122 months ago

    Is there something wrong with doas? I thought doas was smaller with less of an attack surface.

      • @refalo
        link
        22 months ago

        Is that similar to visudo?

        • @[email protected]
          link
          fedilink
          02 months ago

          Not really visudo is only to edit the sudoers file. sudoedit is a better way to edit system files.

          1. Temporary copies are made of the files to be edited with the owner. set to the invoking user.

          2. The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.

          3. If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed.

    • @ericjmorey
      link
      42 months ago

      It seems Poettering is convinced doas, while decreasing attack surface, depends on SUID binary implementation which is a concern in its own right. Poettering is trying to eliminate that dependency in his `run0’ implementation to reduce the attack surface even further.

      The relevant excerpt from the long chain of posts from Poettering’s mastodon.social account is copied below:

      … led various people to revisit the problem and come up with alternatives: most prominently there’s probably OpenBSD’s sudo replacement called “doas”. While it greatly simplifies the tool and removes much of the attack surface, it doesn’t change one key thing: it’s still a SUID binary.

      I personally think that the biggest problem with sudo is the fact it’s a SUID binary though – the big attack surface, the plugins, network access and so on that come after it it just make the key problem… … worse, but are not in themselves the main issue with sudo.

      SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended for and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice…

      … enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.

      So, in my ideal world, we’d have an OS entirely without SUID. Let’s throw out the concept of SUID on the dump of UNIX’ bad ideas. An execution context for privileged code that is half under the control of unprivileged code and that needs careful, … … manual clean-up is just not how security engineering should be done in 2024 anymore.

      With systemd v256 we are going one step towards this. There’s a new tool in systemd, called “run0”. Or actually, it’s not a new tool, it’s actually the long existing tool “systemd-run”, but when invoked under the “run0” name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under…

      … the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.

      Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

      One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways. Except that…

      it doesn’t bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel’s local identification mechanisms.

      run0 doesn’t implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients be authorized by priv servers.

      By isolating the contexts and the resources of client and target we remove some other classes of attacks…

      … entirely, for example this stuff:

      https://ruderich.org/simon/notes/su-sudo-from-root-tty-hijacking

      But enough about all that security blabla. The tool is also a lot more fun to use than sudo.

      Read the rest where he explains run0’s use and functionality beyond the design logic.

      • @mikyopii
        link
        22 months ago

        Thanks for the insight. I think I understand what he is trying to do but is a little too low-level for me to really grasp the technicalities.

    • @refalo
      link
      32 months ago

      it is. arguing attack surface with systemd IMO is a losing battle though.

      • @ericjmorey
        link
        22 months ago

        Why do you say that? It seems that Poettering’s reasoning for avoiding SUID binaries is sound.

    • @[email protected]
      link
      fedilink
      English
      22 months ago

      Some scripts or programs assume sudo by default. It’s a stupid thing but also annoying.

    • 4wd
      link
      -22 months ago

      The main problem with sudo and doas is that they are not developed by Lennart. Seriously.

      • @refalo
        link
        12 months ago

        I consider that a positive.

  • @bitfucker
    link
    72 months ago

    From what I’ve read, wouldn’t this tool become a replacement in the same way wayland replace x11 (different method of escalation and all)? I guess what I was thinking is more like a sudo alternative, like doas for example. In any case, would change like this break a lot of workflow? If so, I doubt it will be the replacement soon.

    • systemd is the opposite of Wayland.

      Wayland took a monolithic system (Xorg) and broke it apart (Wayland, compositors) to try to make a smaller, cleaner codebase with separation of concerns.

      systemd took an already separated system of discrete, interchangeable components and, like a katamari, rolls along absorbing services and clumping them together into one giant monolithic system. It started out as a replacement for init.d, and then decided it needed to absorb syslog, and then crond, and then mounting /home, and now it wants sudo.

      systemd is the “see:” in the definition of “feature envy.” Of you look up the “the Unix philosophy”, systemd is the exact opposite; people who oppose systemd don’t do it for no reason; they oppose it because it violates every tenant of the Unix philosophy.

      I would guess the Wayland people would be aghast at the comparison.

        • But all inter-dependent. C.f. the massive effort and blogs about the PITA the folks who try to keep a fork of systemd’s elogind alive. All of the tools are tightly coupled, which is why they violate the Unix philosophy. It’s not that they’re all under one umbrella; if that were the case, GNU itself would not follow the philosophy; it’s because you can’t run any single component without the whole systemd system. And it’s hard - and sometimes impossible - to swap out something else for anything that systemd has assimilated. Try building a system that uses systemd for init but one of the other syslog projects instead of systemd’s journald. And you can use crond instead of systemd timers, but you’re gonna get systemd timers whether or not you use crond, so now you just have dead code that you can’t remove or disable.

          Coupling, man*. It’s about tight coupling, not whether there are different executables for functions or not.

          ^(*) gender assumption disclaimer: used in the generic, not specific, definition^

          • @[email protected]
            link
            fedilink
            32 months ago

            “but all interdependent”

            As it fucking should be! Yes the tools should be aware of each other. Yes the tools should be integrated. Yes, the tools should not have a bunch of different ways and formats for their config files.

            These are not optional components of a system. I’d rather they work together, instead of needing yet another project in between as a kludge

            • TechNom (nobody)
              link
              English
              32 months ago

              The problem is that all of those interdependent parts and software that are dependent on it become entrenched. There is no freedom to replace individual parts with an alternative because something else will break. That’s what I call ‘Modular in theory, monolithic in practice’.

          • @bitfucker
            link
            22 months ago

            I mean systemd didn’t force any distro to use their software nor force any other developer to assume systemd is present. Any software that assumes systemd is present is not the fault of systemd itself, in fact I’d argue it is a sign of its success. Argue all you want about systemd being monolithic and single point of failure, at the end of the day, software dev needs some tools, and if systemd already provides it but other software doesn’t, of course they will choose systemd.

        • @saiarcot895
          link
          English
          92 months ago

          It’s a set of smaller tools that are developed in the same repository and all released together, all sharing some amount of code.

          That basically makes it monolithic, even if there’s separate binaries that the user calls.

            • @saiarcot895
              link
              12 months ago

              You mean the Linux kernel specifically? I think most people do regard it as a monolithic kernel, even if there are modules you can load and unload.

      • @bitfucker
        link
        12 months ago

        I mean in the sense that they are replacing the method of escalation, I will not talk about its overall architecture as that is a whole can of worms. I am well aware of how SystemD works and its problem too.

  • 4wd
    link
    12 months ago

    This way we will have multiple sudo-tools on one system without the ability to remove all but one. Like now with all this crap like systemd-resolved, systemd-networkd, systemd-anothershitd and a bunch of tools that do the same thing, but are all required.

    • @ericjmorey
      link
      22 months ago

      That doesn’t seem to clear up anything other than indicating that the fork was motivated by wanting to do things differently for the sake of being able to do things differently.

      Which is fine, I do this often enough. But I don’t expect to get a lot of others to follow suit on that basis alone.

    • Twig
      link
      fedilink
      English
      12 months ago

      You’ve got Artix if you’re a Arch fan too

    • @FizzyOrange
      link
      112 months ago

      You were so preoccupied wondering what asinine comment you could make that you never bothered to read the article and learn the reasons that they should.