• nifoc@lemm.ee
    link
    fedilink
    English
    arrow-up
    53
    arrow-down
    14
    ·
    6 months ago

    This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.

    And I hope people realize that systemd is not one large thing, but a (large) collection of tools.

    • DefederateLemmyMl@feddit.nl
      link
      fedilink
      English
      arrow-up
      37
      arrow-down
      6
      ·
      6 months ago

      The attack surface will be a systemd daemon running with UID=0 instead, because how else are you going to hand out root privileges?

      So it doesn’t really change anything to the attack surface, it just moves it to a different location.

      • Kwdg@discuss.tchncs.de
        link
        fedilink
        arrow-up
        4
        arrow-down
        5
        ·
        6 months ago

        That already exists. systemd-run is already available today. So the attack surface would be smaller

        • DefederateLemmyMl@feddit.nl
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          1
          ·
          6 months ago

          Not really, because you’re now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo’s existing code, the attack surface is exactly the same.

    • MonkderDritte@feddit.de
      link
      fedilink
      arrow-up
      23
      arrow-down
      6
      ·
      edit-2
      6 months ago

      that systemd is not one large thing, but a (large) collection of tools.

      Who don’t work without Systemd. And Systemd can’t coexist with tools in the same repo doing the same job in a portable way.

      I think Chimera was it (?) which tried to have Systemd and Runit and others in the same repo. With lots of wrappers and shims. Not because of Runit & co.

      • lemmyreader@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        ·
        6 months ago

        Right. That reminds of the time I was visiting a friend who had broken his Linux computer (No, not “apt-get remove --purge systemd” but they did something slightly similar). When I booted from a live Linux, used chroot and wanted to use configure networking : FAIL because systemd was … not running. As he had no Internet because of his broken machine this caused some delays in fixing this but we got the job done eventually.

    • lemmyreader@lemmy.ml
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      11
      ·
      edit-2
      6 months ago

      This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.

      And I hope people realize that systemd is not one large thing, but a (large) collection of tools.

      XZ-utils rings a bell ? It was among others Debian wanting to pull in part of a systemd tool into openssh and that almost turned into a world wide disaster :(

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        16
        arrow-down
        2
        ·
        6 months ago

        I didnt understand that sentence. Is that what you meant?

        Among other things, Debian wanted to integrate a part of the systemd tools into openssh, which almost led to a worldwide catastrophe

        xz is not part of systemd or openssh afaik.

        • lemmyreader@lemmy.ml
          link
          fedilink
          English
          arrow-up
          14
          arrow-down
          4
          ·
          6 months ago

          You didn’t follow the XZ-utils story ? The malicious actor worked for years on that XZ backdoor that targeted the fact that some Linux distributions were modifying their openssh package to enable systemd notifications.

          • boredsquirrel@slrpnk.net
            link
            fedilink
            arrow-up
            7
            arrow-down
            7
            ·
            6 months ago

            Ok true, it was a systemd dependent issue. But it only makes sense to have those notifications. The problem is dependency on small hardly maintained products, which systemd will improve by centralizing it.

            • Macros@feddit.de
              link
              fedilink
              arrow-up
              4
              arrow-down
              1
              ·
              6 months ago

              And where do maintainers for the new parts of systemd come from? The larger systemd grows the more parts of it will be neglected. Also in regard to people checking commits, opening up doors for exploits like the one in xz.

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

              But it only makes sense to have those notifications.

              Maybe in your mind it makes sense. Going for ease of use rather than security is not something that OpenBSD would quickly do. If you read some more about what “jwz” has to say about all the screensaver bugs in Linux, like here : https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition and realize what a mess that Linux maintainers are making again and again, and then have a look at Debian and their packaging of xscreensaver. Guess what ? Debian added some systemd thingie to xscreensaver. 🤯

              I like Debian since a long time and I use it. But the tinkering of Debian package maintainers and always wanting to do things the Debian way is not something I am always very pleased with. Remember the OpenSSL Debian fiasco ? That shows a problem with Debian which may still exist. Too many packages, not enough maintainers with enough spare time, and no coherent team work of a security team.

              • boredsquirrel@slrpnk.net
                link
                fedilink
                arrow-up
                1
                ·
                6 months ago

                You are talking about Debian holding back random packages for stability. This is of course not very cool but it needs to be tested.

                I am very much in favor of isolate app environments controlled by upstream devs, containerized and with a permission system. The system is made by the distro, and can be stable and very tested, and the apps are simply isolated and made by upstream.

                There is no xscreensaver on Wayland and I think this will not come back?

    • lengau@midwest.social
      link
      fedilink
      arrow-up
      2
      ·
      6 months ago

      Kinda feels like writing a script that implements the sudo CLI but calls pkexec would be an easier way to do it. Given that so many systems already come with both sudo and pkexec, do we really need yet another option?

      • chameleon@kbin.social
        link
        fedilink
        arrow-up
        3
        ·
        6 months ago

        The point of this is to implement some form of privilege escalation without the SUID mechanism. sudo, pkexec and doas are all SUID.

    • digdilem@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      6 months ago

      I’ve had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.