• Dracocide@lemm.ee
      link
      fedilink
      Akan
      arrow-up
      39
      arrow-down
      3
      ·
      1 month ago

      I never understood the hate, tbh. A lot of users don’t even care if Sysd is used, as long as it works. So… Since the majority of distros use it… I think it works enough.

      • Grangle1@lemm.ee
        link
        fedilink
        arrow-up
        23
        arrow-down
        2
        ·
        1 month ago

        It seems to me to be mainly from people who are dedicated to the Unix philosophy that programs should do only one thing, and do it well. Tying everything up into systemd doesn’t follow that. I don’t care either, and I don’t mind systemd, but some people care about it enough to throw paragraphs of hate on it wherever it’s mentioned online. And apparently it’s “bloat”, and to some " bloat" is worse than the devil himself.

        • Max-P@lemmy.max-p.me
          link
          fedilink
          arrow-up
          33
          arrow-down
          3
          ·
          edit-2
          1 month ago

          If you dig deeper into systemd, it’s not all that far off the Unix philosophy either. Some people seem to think the entirety of systemd runs as PID1, but it really only spawns and tracks processes. Most systemd components are separate processes that focus on their own thing, like journald and log management. It’s kinda nice that they all work very similarly, it makes for a nice clean integrated experience.

          Because it all lives in one repo doesn’t mean it makes one big fat binary that runs as PID1 and does everything.

          • optissima@lemmy.world
            link
            fedilink
            arrow-up
            13
            ·
            edit-2
            1 month ago

            This is what turned me around: investigating and realizing that it is following the unix philosophy, it’s just under the hood (under the other hood inside the bigger under the hood).

        • pmk@lemmy.sdf.org
          link
          fedilink
          arrow-up
          9
          arrow-down
          1
          ·
          1 month ago

          I bet some of those people use neovim instead of the more unix philosophy ed.

        • laurelraven@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          5
          ·
          1 month ago

          My main issues are that it obfuscates things and seems to consume everything it can into itself.

          Honestly, if it were more transparent and designed in a way to easily facilitate swapping out components with alternatives, I’d be a lot more okay with it.

      • steeznson@lemmy.world
        link
        fedilink
        arrow-up
        11
        ·
        1 month ago

        I think some of the hate is from the main systemd dev, Poettering, being so abrasive on social media. He’s got a hateboner for certain distros (which don’t ship with systemd as the default).

      • HubertManne@kbin.social
        link
        fedilink
        arrow-up
        2
        arrow-down
        2
        ·
        1 month ago

        I understand the concern about the future and we have seen overbloated projects have issues. In the long run though I will use what works best for me and only get into philosophical comparisons if im making the choice between relatively equal options.

  • gaael@lemmy.world
    link
    fedilink
    arrow-up
    70
    arrow-down
    1
    ·
    1 month ago

    The article talks about sudo and doas being SUID binaries and having a larger attack surface than run0 would. Could someone ELI5 what this means?

    • Max-P@lemmy.max-p.me
      link
      fedilink
      arrow-up
      216
      arrow-down
      1
      ·
      1 month ago

      Basically, the SUID bit makes a program get the permissions of the owner when executed. If you set /bin/bash as SUID, suddenly every bash shell would be a root shell, kind of. Processes on Linux have a real user ID, an effective user ID, and also a saved user ID that can be used to temporarily drop privileges and gain them back again later.

      So tools like sudo and doas use this mechanism to temporarily become root, then run checks to make sure you’re allowed to use sudo, then run your command. But that process is still in your user’s session and process group, and you’re still its real user ID. If anything goes wrong between sudo being root and checking permissions, that can lead to a root shell when you weren’t supposed to, and you have a root exploit. Sudo is entirely responsible for cleaning the environment before launching the child process so that it’s safe.

      Run0/systemd-run acts more like an API client. The client, running as your user, asks systemd to create a process and give you its inputs and outputs, which then creates it on your behalf on a clean process tree completely separate from your user session’s process tree and group. The client never ever gets permissions, never has to check for the permissions, it’s systemd that does over D-Bus through PolKit which are both isolated and unprivileged services. So there’s no dangerous code running anywhere to exploit to gain privileges. And it makes run0 very non-special and boring in the process, it really does practically nothing. Want to make your own in Python? You can, safely and quite easily. Any app can easily integrate sudo functionnality fairly safely, and it’ll even trigger the DE’s elevated permission prompt, which is a separate process so you can grant sudo access to an app without it being able to know about your password.

      Run0 takes care of interpreting what you want to do, D-Bus passes the message around, PolKit adds its stamp of approval to it, systemd takes care of spawning of the process and only the spawning of the process. Every bit does its job in isolation from the others so it’s hard to exploit.

        • Drusenija@lemmy.world
          link
          fedilink
          arrow-up
          103
          ·
          1 month ago

          (I’ll attempt this based on my understanding of both)

          Pouring a cup of juice is something an adult needs to be involved with.

          sudo is when you ask for permission to pour your own cup of juice. You ask an adult, they give you the cup and the juice, and then you’re responsible for pouring it. If the adult isn’t paying attention they may leave the fridge open for you to go back for more juice or another beverage, but otherwise you’re limited to the amount of juice the adult has given you.

          run0 is when the adult just gets you a cup of juice. You tell them what you want, they go and pour the juice, and just give you the cup with the juice in it. You never enter the kitchen, so you don’t have access to the fridge, just your cup of juice.

        • Max-P@lemmy.max-p.me
          link
          fedilink
          arrow-up
          34
          ·
          1 month ago

          Some executables are special. When you run them, they automagically run as root instead! But if sudo isn’t very, very careful, you can trick it into letting you run things as root that you shouldn’t be able to.

          Run0 DM’s systemd asking it to go fork a process as root for you, and serves as the middleman between you and the other process.

      • NuclearDolphin@lemmy.ml
        link
        fedilink
        English
        arrow-up
        20
        ·
        1 month ago

        Sounds good in theory.

        But I’ve had so many issues with D-Bus fucking shit up on my systems that I’d be very reluctant to hinge my only way of recovering from failures upon something so brittle.

        Granted, D-Bus hasn’t given me any trouble since moving to NixOS. The hell of trying to recover my arch systems from a perpetually failing D-Bus would make me very apprehensive to adopt this. I could see myself using run0 by default, but keeping sudo-rs or doas around with a much stricter configuration as a failsafe until the run0 + D-Bus + PolKit is absolutely stable and bulletproof.

        • Max-P@lemmy.max-p.me
          link
          fedilink
          arrow-up
          9
          ·
          1 month ago

          I haven’t had D-Bus problems in quite a while but actually run0 should help with some of those issues. Like, systemctl --user will actually work when used with run0, or at least systemd-run can.

          Haven’t used it yet so it’s all theoretical, but it makes sense to me especially at work. I’ve used systemd-run to run processes in very precise contexts, it’s worth using even if just to smush together schedtool, numactl, nice, taskset and sudo in one command and one syntax. Anything a systemd unit can do, systemd-run and run0 can do as well.

          I’m definitely going to keep su around just in case because I will break it the same I’ve broken sudo a few times, but I might give it a shot and see if it’s any good just for funsies.

          Just trying to explain what it does and what it can do as accurately as possible, because out of context “systemd adds sudo clone” people immediately jump to conclusions. It might not be the best idea in the end but it’s also worth exploring.

        • chameleon@kbin.social
          link
          fedilink
          arrow-up
          7
          ·
          1 month ago

          Some people are opposed to sudo being a fairly complex program with an awkward to understand configuration language and a couple of methods that can fetch config from elsewhere. Fixing upstream sudo can’t happen because those features exist and are presumably used by some subset of people, so straight up removing them is not good, but luckily doas and sudo-rs exist as alternatives with a somewhat stripped featureset and less footguns.

          Others are opposed to the concept of SUID. Underneath all the SUID stuff lies far more complexity than is obvious at first sight. There’s a pretty decent chunk of code in glibc’s libdl that will treat all kinds of environment variables differently based on whether an executable is SUID, and when that goes wrong, it’s reported as a glibc bug (last year’s glibc CVE-2023-4911 was this). And that gets all the more weird when fancy Linux features like namespaces get involved.

          Removing SUID requires an entirely different implementation and the service manager is the logical place for that. That’s not just Lennart’s idea; s6, as minimal and straight to the point as it tends to be, also implements s6-sudo{,d,c}. It’s a bit more awkward to use but is a perfectly “Unix philosophy” style implementation of this very same idea.

      • t0m5k1@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        Never had an issue. Might look for a replacement should an issue arise. Been driving Linux since sarge.

    • Para_lyzed@lemmy.world
      link
      fedilink
      arrow-up
      23
      ·
      edit-2
      1 month ago

      SUID stands for Set User ID. An SUID binary is a file that is always run with the UID of the owner user (almost always root). Note that this does not require that the user running them has root permissions, the UID is always changed. For instance, the ping command needs to set up network sockets, which requires root permissions, but is also often used by non-root users to check their network connections. Instead of having to sudo ping, any normal user is able to just run ping, as it uses SUID to run as the root user. sudo and doas also require functions that necessitate them running as root, and so if you can find out how to exploit these commands to run some arbitrary code without having to authenticate (since authentication happens after the binary has started running), there is a potential for vulnerabilities. Specifically, there is the privilege escalation, which is one of the most severe types of vulnerabilities.

      run0 starts using systemd-run, which does not use SUID. Instead, it runs with the permissions of the current user, and then authenticates to the root user after the binary has already started to run. systemd-run contacts polkit for authentication, and if it succeeds, it creates a root PTY (pseudo-terminal/virtual terminal), and sends information between your session and the root PTY. So this means that in order to achieve privilege escalation with run0 as root, you have to actually authenticate first, removing the “before authentication” attack surface of sudo and doas.

      TL;DR SUID binaries will always run as the owner (usually root), even before any form of authentication. run0 will start with the permissions of the current user, and then authenticate before running anything with root permissions.

    • ryannathans@aussie.zone
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      1 month ago

      Suid is a bit set on executables that results in them being run as the user that owns the file without needing a password, for example, passwd as root.

      Run0 ignores this bit

      • flux@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        What a nice succinct explanation!

        But also completely useless. Run0 ignores the suid bit for the same reason as 99% of command line apps do: it ignores because it isn’t relevant to its functionality.

    • purplemonkeymad@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      1 month ago

      Did they think about how far I would have to move my hand to type it? Sudo is only in two easy to reach places on the keyboard, run0 is 4 separate areas of the keyboard, one two rows from home and none on the home row.

      I’m only partially joking.

    • laurelraven@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      21
      arrow-down
      1
      ·
      1 month ago

      I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, SystemD/Linux, or as I’ve recently taken to calling it, SystemD plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning SystemD system made useful by the SystemD corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

      Many computer users run a modified version of the SystemD system every day, without realizing it. Through a peculiar turn of events, the version of SystemD which is widely used today is often called Linux, and many of its users are not aware that it is basically the SystemD system, developed by the SystemD Project.

      There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the SystemD operating system: the whole system is basically SystemD with Linux added, or SystemD/Linux. All the so-called Linux distributions are really distributions of SystemD/Linux!

  • Yozul@beehaw.org
    link
    fedilink
    arrow-up
    50
    arrow-down
    5
    ·
    1 month ago

    This is fine, but why does everything need to be part of Systemd? Like, seriously, why can’t this just be an independent project? Why must everything be tied into this one knot of interdependent programs, and what’s going to happen to all of them when the people who are passionate about it and actually understand all the stupid ways they interrelate move on with their lives? Are we looking at the formation of the next Xorg? Will everybody being scrambling to undo all of this in another 20 years when we all realize it’s become an unmaintainable mess?

    • Melmi@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      34
      arrow-down
      1
      ·
      edit-2
      1 month ago

      Systemd does a lot of things that could probably be separate projects, but run0 is an example of something that benefits from being a part of systemd. It ties directly into the existing service manager to spawn new processes.

      • nous@programming.dev
        cake
        link
        fedilink
        English
        arrow-up
        9
        arrow-down
        1
        ·
        1 month ago

        Systemd does a lot of things that could probably be separate projects,

        I dont get the hate for this - Linux is full of projects that do the same thing: coreutils, busybox, kde, gnome, different office suites, even the kernel itself. It is very common for different related projects to be maintained together under the same project/branding with various different levels of integration between them. But people really seem to only hate on systemd for this…

        • Yozul@beehaw.org
          link
          fedilink
          arrow-up
          4
          ·
          1 month ago

          I guess for me the difference is that the kernel is just way beyond what I can understand and has never had any viable alternatives, gnome I really don’t like, and everything else you listed is just collections of simple stuff that aren’t actually very interdependent. Systemd is a giant mess of weirdly interdependent things that used to be simple things. Sure, some of them weren’t great, but every major distro abandoning all of the alternatives feels like putting all of our eggs in one basket that’s simultaneously getting more important and more fragile the bigger it gets.

          • nous@programming.dev
            cake
            link
            fedilink
            English
            arrow-up
            4
            ·
            1 month ago

            Except desktop environments - they are far from a simple loosely collection of simple stuff. They coordinate your whole desktop experience. Apps need to talk to them a lot and often in ways specific to a single DE. Theming applications is done differently for every toolkit there is, startup applications (before systemd) is configured differently, global shortcuts are configured differently by each one… If anything it is something you interact with far more than systemd and has far more inconsistencies between each one. Yet few people complain about this as much as they complain about systemd.

            Systemd is a giant mess of weirdly interdependent things that used to be simple things.

            They used to be simple things back when hardware and the way we use computers were much simpler. Nowadays hardware and computers are much more dynamic and hotplugable and handle a lot more state that needs to persist and be kept track of. https://www.youtube.com/watch?v=o_AIw9bGogo is a great talk on the subject and talks about why systemd does what it does.

          • nous@programming.dev
            cake
            link
            fedilink
            English
            arrow-up
            4
            ·
            edit-2
            1 month ago

            What standards? The old init systems were a loose collection of shell scripts that were wildly different on every distro. Other tools like sudo also broke the established standards of the time, before it you had to login as root with the root password.

            Even gnome and KDE have their own themeing standards as well as other ways of doing things. Even network manager is its own standard not following things that came before it. Then there are flatpack, snaps and app images. Not to mention deb vs rpm vs pacman vs nix package formats. Loads of things in Linux userland have broken or evolved the standards of oldern times.

            • AVincentInSpace@pawb.social
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 month ago

              Systemd breaks its own standards. Oh, were you making a replacement for this component of systemd that does some things the systemd version doesn’t? Well the latest version of systemd just changed the Unix socket protocol that it uses to communicate with the rest of systemd from text based to binary. Sorry for the lack of warning.

              • Christopher Goss@aus.social
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                1 month ago

                @AVincentInSpace @nous I’ve always disliked the arrogance of the lead Dev & the inexorable incremental usurping of Linux functionality. I’m deeply uncomfortable with so much being absorbed into a big binary black box

      • flying_sheep@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        1 month ago

        Yeah, if all those complainers want something more modular, they’re free to push for protocols that allow to leverage existing components while also allowing for them to come from multiple vendors.

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      25
      arrow-down
      1
      ·
      1 month ago

      It seems a fairly explicit goal of systemd to redefine Linux as a unified platform rather than as a kernel that can run any one of many implementations of many different services. I assume this is not just the systemd lead but also a goal of Red Hat.

      Personally, while I am ok with systemd defining itself as a single source for all this functionality, I hate that they are taking away ( or making it hard at least ) to have independent implementations of these services.

      What Chinera is doing with dinit and turnstile is really interesting. It would be nice to have feature comparable approaches to the systemd monolith that distributions could choose from.

      • lemmyreader@lemmy.ml
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 month ago

        What Chinera is doing with dinit and turnstile is really interesting. It would be nice to have feature comparable approaches to the systemd monolith that distributions could choose from.

        Link for other readers about Chimera Linux, dinit, turnstile : https://chimera-linux.org/development

    • Kusimulkku@lemm.ee
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      1 month ago

      It does make sense for me to have this functionality in systemd the way they want to go about doing this.

      • Yozul@beehaw.org
        link
        fedilink
        arrow-up
        4
        ·
        1 month ago

        Okay, but why go about it that way? That can’t be the only way of making a viable alternative to sudo. Why does everything need to be part of one project? If you want to reuse code why not spin it out into a library so each component can be installed with just the libraries it needs and not the depending on the whole gigantic thing? KDE works that way. It’s obviously possible for some things, at least.

        One of my favorite things about Linux is simply fiddling around and finding the things I like and don’t and just using the ones I do. I can’t do that effectively with systemd though. Sure, it’s theoretically modular, and there are even a couple parts left that can work independently, but mostly it’s just one big block of half an operating system that all gets lumped together into one gigantic mess, and I can’t effectively just use the bits I like. It’s kind of all or nothing, and then maybe being allowed to double up on some of the things I’d like to use an alternative to… for now. It just kinda sucks the joy out of using my computer, but trying to avoid it completely is a massive pain in the butt.

        There’s no big dramatic thing wrong with systemd. Using systemd and being happy with it is a good thing. I do not object to the existence of systemd. Systemd is fine. It just makes me like Linux less is all. I am enjoying my time with my computer less than I used to, and the universal dominance of systemd is probably the biggest reason for that.

  • Eugenia@lemmy.ml
    link
    fedilink
    English
    arrow-up
    34
    arrow-down
    1
    ·
    1 month ago

    I personally don’t have a problem with run0 over sudo, however, I don’t want to have to remember to use a different command on the terminal. Just rename it “sudo”, and do the new stuff with it. Just don’t bother me having to remember new commands.

    • TechNom (nobody)@programming.dev
      link
      fedilink
      English
      arrow-up
      15
      ·
      edit-2
      1 month ago

      You can uninstall the sudo application and add sudo as an alias for run0 in your shell initialization script. That’s better than them renaming run0 to sudo, because that will prevent people from running the real sudo if they want it.

  • jeremyparker@programming.dev
    link
    fedilink
    arrow-up
    39
    arrow-down
    7
    ·
    edit-2
    1 month ago

    Me: Oh, I get it, this “Lemmy” website – it’s like The Onion but for nerds?

    My fellow lemmings: No, they’re serious. run0 is real.

    Me: Hah. The Onion, but for nerds! I love it.

  • ancap shark@lemmy.today
    link
    fedilink
    arrow-up
    28
    ·
    1 month ago

    Will this be an integral part of systemd, or will they release it as a separate thing? I mean, if I like it, but I’m not using systemd (I do use it, but I’m just thinking about it), could I use this run0 (horrible name) without having to buy into all of systemd?

    • Brunacho@scribe.disroot.org
      link
      fedilink
      English
      arrow-up
      30
      ·
      1 month ago

      it’s just a link to systemd-run which is a part of systemd, i doubt it works separately.

      but, if you use s6 as an alternative init system, s6-sudo is a somewhat equivalent aproach to how run0 works (instead of systemd-run it calls s6-ipcclient)

    • Heavybell@lemmy.world
      link
      fedilink
      English
      arrow-up
      13
      ·
      1 month ago

      The article says it works by messaging systemd to run the process as the given user, rather than being a SUID binary. So it wouldn’t work without systemd.

  • Fizz@lemmy.nz
    link
    fedilink
    arrow-up
    39
    arrow-down
    11
    ·
    1 month ago

    Sounds good. It’s a win win. People that doesn’t like the system d implementation can use doas or keep sudo. I Hate the name though. Run0 is dumb can’t they just steal the name doas

        • shadowtofu
          link
          fedilink
          English
          arrow-up
          16
          ·
          1 month ago

          Then the editor, all extensions, language servers, etc. are all running as root.

  • e8d79
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    1 month ago

    I really don’t care about the command I use to get elevated privileges. On my Debian servers I use su and maybe in future, if Fedora decides to make the switch, I will use run0.

  • SwingingTheLamp@midwest.social
    link
    fedilink
    English
    arrow-up
    30
    arrow-down
    25
    ·
    1 month ago

    This just sounds like a bad idea, a solution in search of a problem. Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code. It’s also a very fundamental piece of the system that you want to always work, even (especially!) when other things get borked. The brief description of run0 already has too many potential points of failure.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      47
      arrow-down
      1
      ·
      1 month ago

      sudo is a setuid binary, but it’s a fairly simple program

      Sudo is actually fairly huge and complex. Alternatives like really or doas or su are absolutely tiny by comparison.

    • lemmyreader@lemmy.ml
      link
      fedilink
      English
      arrow-up
      21
      ·
      1 month ago

      Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code.

      Have to trust the code ? doas for OpenBSD was created because of issues with sudo.

      Talking with deraadt and millert, however, I wasn’t quite alone. There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough.

    • Max-P@lemmy.max-p.me
      link
      fedilink
      arrow-up
      18
      ·
      1 month ago

      I’ve actually ran into some of those problems. If you run sudo su --login someuser, it’s still part of your user’s process group and session. With run0 that would actually give you a shell equivalent to as if you logged in locally, and manage user units, all the PAM modules.

      systemd-run can do a lot of stuff, basically anything you can possibly do in a systemd unit, which is basically every property you can set on a process. Processor affinity, memory limits, cgroups, capabilities, NUMA node binding, namespaces, everything.

      I’m not sure I would adopt run0 as my goto since if D-Bus is hosed you’re really locked out and stuck. But it’s got its uses, and it’s just a symlink, it’s basically free so its existence is kBs of bloat at most. There’s always good ol su when you’re really stuck.

    • Para_lyzed@lemmy.world
      link
      fedilink
      arrow-up
      14
      ·
      edit-2
      1 month ago

      sudo is not a fairly simple program. Last I checked, it had ~177k lines of code. It provides functionality far beyond what is needed of an average user. doas is a simpler alternative (also using SUID) at ~3k lines of code. It comes from OpenBSD. There is absolutely a problem when it comes to SUID binaries. If you can find a way to exploit the permissions given at the start of the SUID binary before user authentication occurs (since the UID is set before the binary runs), you have yourself a full privilege escalation vulnerability. systemd is very well integrated with the distros that use it, being the first process to run after the kernel is initialized. There will never be a point at which systemd is not functioning, but the rest of your system is perfectly fine. It is an absolutely necessary part of the system (assuming your distro uses it), and if it goes down, you have to restart your system. As such, I don’t see any validity to the statement “you want to always work, even (especially!) when other things get borked”. What exactly do you see as being an issue with run0? What specific part of its implementation do you seem to have a problem with? It’s just a symlink to systemd-run, which is already very well tested and has been around for a long time. It’s also far simpler than sudo, and removes the attack surface of running an SUID binary of its size. What “points of failure” do you see here, exactly?

    • unknowing8343
      link
      fedilink
      arrow-up
      14
      ·
      1 month ago

      I have 0 knowledge of these things, but I do know that people always comment that sudo is bloated, that nobody is truly using everything that sudo can do, only one basic command.

      • The Doctor@beehaw.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 month ago

        Nobody is using all of sudo’s features because those features are for different use cases. Case in point, LDAP support. At home, pretty much nobody uses it. But on the job, where there are tens to hundreds of machines that someone might need, and they’re all hooked into LDAP for centralized authentication management, it makes sense to have that built into sudo. Same with Kerberos support - at home, forget it, but in a campus environment where Kerberos (and possibly AFS) are part of the network, it makes sense.

    • Zucca@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      10
      arrow-down
      1
      ·
      1 month ago

      sudo is a setuid binary, but it’s a fairly simple program

      Some people would disagree to this.

      The brief description of run0 already has too many potential points of failure.

      If the “listener” is PID1, which will run the privileged command, in theory, it would be quite bullet proof (in a working system PID1 is always there). But since this is systemd, PID1 is much more than that and much more complex. On the other hand spawning another daemon from PID1 to be the “listener” makes it, perhaps, even more complicated. You’d have to make sure the listener is always running and have some process supervisor there to watch if it exits… and maybe even a watchdog polling it to make sure it isn’t frozen.

      So my conclusion is the same as yours:

      a solution in search of a problem

      We already have a working solution. Have a well written SUID program. I’ve been using doas for some years now. It’s simple enough that I trust it.

      • lemmyvore@feddit.nl
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        1 month ago

        I’ve always wondered why we even bother with SUID commands. Why not just log in as root?

        • Kata1yst@kbin.social
          link
          fedilink
          arrow-up
          7
          ·
          1 month ago

          On a server, it allows you to track who initiates which root season session. It also greatly minimizes the attack surface from a security perspective to have admin privileged accounts unable to be remotely connected to.

          • lemmyvore@feddit.nl
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 month ago

            On a server, it allows you to track who initiates which root season session.

            Wouldn’t separate SSH keys achieve the same?

            greatly minimizes the attack surface from a security perspective to have admin privileged accounts unable to be remotely connected to.

            Really? How, exactly? Break the ssh key authentication? And wouldn’t that apply to all accounts equally?

            • Kata1yst@kbin.social
              link
              fedilink
              arrow-up
              4
              ·
              1 month ago

              Wouldn’t separate SSH keys achieve the same?

              Separate ssh keys for the user and the admin? Yeah, see point 2, admins should not be remotely accessible.

              Really? How, exactly? Break the ssh key authentication? And wouldn’t that apply to all accounts equally?

              Keys aren’t perfect security. They can easily be mishandled, sometimes getting published to GitHub, copied to USB drives which can easily be lost, etc.

              Further, there have been attacks against SSH that let malicious actors connect remotely to any session, or take over existing sessions. By not allowing remote access on privileged accounts, you minimize risk.

              Forcing a non privileged remote session to authenticate with a password establishes a second factor of security that is different from the first. This means a cracked password or a lost key is still not enough for a malicious actor to accomplish administrative privileges.

              A key is something you have

              A password is something you know

              So, by not allowing remote privileged sessions, we’re forcing a malicious actor to take one more non-trivial step before arriving at their goals. A step that will likely be fairly obvious in logs on a monitored machine.

              • lemmyvore@feddit.nl
                link
                fedilink
                English
                arrow-up
                1
                arrow-down
                1
                ·
                edit-2
                1 month ago

                If I get into your non-privileged account I can set up a program that acts like sudo and I bet 99% of people will never notice they just gave their password away. And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.

                And if I can’t break into your non-privileged account then I can’t break into a privileged account either.

                These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.

                • Kata1yst@kbin.social
                  link
                  fedilink
                  arrow-up
                  4
                  ·
                  1 month ago

                  I strongly disagree with your premise. Separating authentication and privilege escalation adds layers of security that are non-trivial and greatly enhance resilience. Many attacks are detected and stopped at privilege escalation, because it happens locally before a user can stop or delete the flow of logs.

                  If I get into your non-privileged account I can set up a program that acts like sudo

                  No you cannot. A non privileged user doesn’t have the access necessary to run a program that can accomplish this.

                  And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.

                  Once again, you didn’t privilege escalate, because once you have a foothold (authentication) you don’t have the necessary privileges, so you must perform reconnaissance to identify an exploitable vector to privilage escalate with. This can be any number of things, but it’s always noisy and slow, usually easy to detect in logs. There is a reason the most sophisticated attacks against well protected targets are “low and slow”.

                  And if I can’t break into your non-privileged account then I can’t break into a privileged account either.

                  You’re ignoring my points given regarding the risks of compromised keys. If there are no admin keys, there are no remote admin sessions.

                  These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.

                  Spoken like someone who has never red teamed or purple teamed. Even admin accounts are untrusted, given only privileges specific to their role, and closely monitored. That doesn’t mean they should have valid security measures thrown away.

        • TimeSquirrel@kbin.social
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          1 month ago

          We used to do that a lot, in the 90s and early 2000s. We determined that that’s not a good idea. People even ran DEs under root.

          • lemmyvore@feddit.nl
            link
            fedilink
            English
            arrow-up
            2
            arrow-down
            1
            ·
            1 month ago

            I’m not saying to run everything as root but most of the reasons given for sudo are bull. This blog post makes a good job of debunking them.

        • atzanteol@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 month ago

          sudo and friends allow you to gain root access while not enabling the root account. If the root account has no credentials then nobody is guessing your password and logging in as an admin.

          On a multi-user system it allows for multiple admins without sharing a password. It also allows providing admin access for “some” things but not others.

          • lemmyvore@feddit.nl
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 month ago

            If the root account has no credentials then nobody is guessing your password and logging in as an admin.

            They just need to log in as you and trick you into entering your password in a seemingly legit prompt.

            On a multi-user system it allows for multiple admins without sharing a password.

            Multiple distinct ssh keys do the same. As long as everybody ends up doing things as the same user it’s all moot anyway.

            It also allows providing admin access for “some” things but not others.

            Can I provide selective access to just some files? Just some network interfaces? Just some ports? Just some parts of RAM or CPU? Without being able to change those limits?

              • lemmyvore@feddit.nl
                link
                fedilink
                English
                arrow-up
                2
                ·
                1 month ago

                The point I’m trying to make is that having just one “super” account for everything is a very poor idea. A lot of work has gone into filtering access to the root account and very little into getting rid of the root account. Ideally nothing should run as root, it should run as individual accounts with varying levels of access on a need-to-have basis.

                • atzanteol@sh.itjust.works
                  link
                  fedilink
                  English
                  arrow-up
                  3
                  ·
                  1 month ago

                  "That’s* what you meant when you said this???

                  I’ve always wondered why we even bother with SUID commands. Why not just log in as root?

        • Zucca@sopuli.xyz
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 month ago

          Yeah. I keep one root tmux session open on my main PC for administrative tasks.

    • huf [he/him]@hexbear.net
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      1
      ·
      1 month ago

      it took less than a day for someone to break run0 totally open, so basically, you have a choice between a well tested/debugged sudo and this new thing which may eventually mature

    • jbk
      link
      fedilink
      arrow-up
      3
      arrow-down
      2
      ·
      1 month ago

      It does something different and doesn’t ask to replace sudo everywhere. You brainless trashtalkers can’t even read an article before you judge.