And it's subsuming another bit of Linux by replacing sudo
    • tal@lemmy.todayEnglish
      11·
      11 days ago

      Poettering in Mastodon thread:

      sudo has serious problems though. It’s a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on.

      Okay, fine. So surely he’s going to make a single tool that does one thing in an isolated box that doesn’t pull in any unnecessary functionality.

      Poettering a few posts down:

      But enough about all that security blabla. The tool is also a lot more fun to use than sudo. For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges.

      This is so Poettering. I don’t want a privilege-escalation tool altering the display. Why in God’s name is this not in the shell? What’s going to happen on terminals that can’t handle colors? Are you going to deal with them correctly? Is your “small” tool now going to be handling terminfo?

      Every time that guy sees something, he thinks “let’s just rewrite everything from scratch, break the existing tool boundaries, and other people will fix the fallout”.

      • tal@lemmy.todayEnglish
        5·
        11 days ago

        Well, he’s been employed by Microsoft for the past two years, so you’re halfway there.

      • Akatsuki Levi@lemmy.worldEnglish
        2·
        12 days ago

        I can’t wait to replace that crap piece of shit of a nvidia gpu that I have for a radeon to replace my main station with Alpine

    • HouseWolf@lemm.eeEnglish
      3·
      12 days ago

      I’ve been playing around with it in a VM and thinking of throwing over my old Windows drive I haven’t used in months to see how well it works on my actual hardware.

      Getting Pipewire setup on it has been a pain in VM and all the fixes others posted online haven’t helped me.

  • pivot_root@lemmy.worldEnglish
    203·
    12 days ago

    Yeah… we didn’t need run0.

    Setuid and sudo work fine, and they’re lightweight. I fail to see how yet another binary is needed for that job, and especially one that relies on polkit. If you really needed to use polkit for gaining privileges temporarily, pkexec already exists for that.

  • nick@midwest.socialEnglish
    162·
    12 days ago

    I can’t wait for the staggering vulnerabilities that come from this. Excited.

  • moonpiedumplings@programming.devEnglish
    206·
    12 days ago

    No one complained when s6, another init system, also offered a sudo alternative (before systemd did, too). But when Poettering does it, it’s bad and wrong and ununixlike!

    Maybe setuid has been extremely problematic, and more than one entity has sought alternatives?

    • pivot_root@lemmy.worldEnglish
      10·
      12 days ago

      If the alternative involves shoving polkit on a server just for temporary admin privileges, it’s unnecessary.

      • moonpiedumplings@programming.devEnglish
        153·
        12 days ago

        You could say the same thing about sudo. Sudo’s codebase is massive, compared to alternatives like doas, but it comes with many features doas does not have, like being able to ask a remote LDAP server if a user will be able to escalate.

        I find it absurd that we have just simply accepted the idea of a setuid binary with built in networking code, as our primary admin escalation tool. 100,000+ lines of C code, code that has had multiple buffer overflow exploits*, in a setuid binary, just for temporary admin privileges. Does that seem necessary to you?

        Polkit provides an alternative to that. If you don’t need the features, then fine, you don’t have to use run0 — but then you can’t use sudo without being a hypocrite. No longer do I have to have rely on a setuid binary that tries to do everything in one program when I really need sudo’s features, instead polkit handles authentication (including asking remote resources if an action is okay), and run0 handles actual escalation.

        In another comment in this thread, you mention sudo being lightweight — which is outright false. Compared to doas or su, it’s extremely heavyweight, and with that complexity comes more risk of vulnerabilities. You also mention pkexec, for executing with polkit, but pkexec is also setuid, and has many of the same pitfalls.

        *Buffer overflow exploits in sudo:

        1. https://arstechnica.com/information-technology/2020/02/serious-flaw-that-lurked-in-sudo-for-9-years-finally-gets-a-patch/
        2. https://blog.qualys.com/vulnerabilities-threat-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit
        • pivot_root@lemmy.worldEnglish
          5·
          12 days ago

          Does sudo have a plethora of stupid features? Yeah.

          What it doesn’t have is a needlessly complicated and overengineered design that relies on interprocess communication and three different daemons from two separate packages. It generates a temporary systemd service to actually run the privileged command, for Davis’ sake. That is one hell of a surface area for something that’s the gateway between an unprivileged user and root.

          I’m not saying sudo deserves to be used permanently, but if someone is going to replace it with a new tool for security reasons, that tool should be less complicated and use fewer runtime dependencies than what it’s replacing. When you account for the entire architecture of run0, sudo is lightweight in comparison.

        • potkulautapaprika@sopuli.xyzEnglish
          2·
          9 days ago

          Better put than I would’ve said. I don’t much care for lennart, but he’s right about some things here. Sudo is unnecessarily huge so it being setuid binary is obviously not great.

          Run0 isn’t probably the solution, but something might emerge one day that handles privilege escalation in a more today’s sane way than sudo.

          Doas is kind of an option, but if you are gonna rework this, makes sense to re-think it more than ‘leaner sudo’. Let’s see what pops up some years later, after all, we all (probably) thought pulseaudio was gonna stay forever too.

  • SpaceNoodle@lemmy.worldEnglish
    13·
    12 days ago

    Moving a potential vulnerability from one place to another just increases risk with the introduction of new unknowns.

    • tal@lemmy.todayEnglish
      10·
      12 days ago

      As much as I am ambivalent about Poettering projects, and as much as I really don’t like the all-encompassing nature of systemd, in my experience, systemd has basically worked.

      PulseAudio, his previous thing, was an absolute dumpster fire in terms of breakage when it came out and continued to be for years. I had multiple systems spanning a number of sound devices that had all kinds of issues with it. It also added a lot of complexity to an already-complex sound stack.

      I haven’t had systemd cause massive problems. At least from a user level, I haven’t seen it create complexity problems.

      It breaks my familiarity with existing tools to some degree. I don’t know how to configure which virtual terminals exist and have a getty process running on them the way I did with traditional init. I don’t know systemd’s runlevel replacement.

      But other software packages have done that too. Iproute2 did that with ip replacing route and ifconfig and similar. And my understanding is that there was a legitimate reason for that transition – IIRC multiple routing tables or something. The command-line Unix world is still pretty good about maintaining UI over time – transitions like this are pretty rare, compared to something like Windows.

      Traditional init didn’t permit for parallel init, which especially in a world with SSDs and many-core processors, is, I think, desirable. I’m not saying that it had to be systemd – could have been Upstart or something. But I think that the switch to some form of init system that permitted parallel init needed to happen.

      There was a real issue that traditionally existed with the concept of a user being locally logged in to the machine and having elevated permissions to physical devices, like sound hardware and CD drives and such, and my vague understanding is that systemd-logind handles some of this. That wasn’t historically handled very well.

      Same thing for hotplugging and systemd-udevd.

      I generally am not happy about a single software package taking a large role in distros, because IME, part of the way that distros can deal with problematic software packages is to drop them in favor of another, and something that is part of a large project has a lot of inertia.

      But…you could say the same thing about GNOME or KDE. They’re both large software projects. They contain things, like a solitaire game, that don’t really need to be part of the larger package. And I don’t see people off trying to break them up. Okay, they aren’t as fundamental to the system, but the same scope creep argument can be made.

      • MigratingtoLemmy@lemmy.worldEnglish
        2·
        12 days ago

        I agree with you, being a system admin, systemd has mostly just worked. It tries to be funny sometimes, but because I work on a server I don’t usually deal with some things that a user might have to work with.

        Another person mentioned a continued usage of SysVInit on Debian: I’m going to try it myself. See how I like it. If it works for me then I’ll drop SystemD completely and even then I get to stick with Debian!

      • MigratingtoLemmy@lemmy.worldEnglish
        2·
        12 days ago

        Maybe I should take a stab at it, I knew it was maintained in some capacity but I thought most of userland would break without Systemd

        • notabot@lemm.eeEnglish
          4·
          11 days ago

          I haven’t seen any breakage, although you may find documentation assumes SystemD. Debian maintains init freedom, and support for sysVinit was improved in Bullseye, so it’s not being forgotten about.

          If you don’t fancy going that route, there are Debian forks that are designed to be SystemD free such as Devuan or MX linux, which defaults to sysVinit. I’ve not tried either, but they seem well regarded, and I’m sure there are others too.

  • KISSmyOSFeddit@lemmy.worldEnglish
    97·
    11 days ago

    My ideal Linux system would consist of only the kernel, systemd, an immutable root file system, and flatpaks.
    Fuck the Unix philosophy, this isn’t the 90’s anymore.

    • Lem453English
      4·
      11 days ago

      So Fedora atomic?

      There’s like a dozen variants as well to suit any specialty application

      • KISSmyOSFeddit@lemmy.worldEnglish
        2·
        11 days ago

        That’s what I currently run. But it still has a lot of stuff installed as rpm.
        I’m curious what Ubuntu’s snap-only system is going to be like. AFAIK they push snaps over flatpaks because flatpaks aren’t suited to using them for the base system utilities while snaps are.

    • corsicanguppyEnglish
      3·
      11 days ago

      As someone involved heavily in OS security after Y2K, I can only say, “FAFO”. This is gonna be good.