• dotslashme@infosec.pub
    link
    fedilink
    English
    arrow-up
    68
    arrow-down
    10
    ·
    2 months ago

    Not that I’m opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.

    • NekkoDroid@programming.dev
      link
      fedilink
      arrow-up
      30
      arrow-down
      10
      ·
      edit-2
      2 months ago

      This isn’t exactly a “new” attack surface, so removing the attack surface that sudo (and alternatives) is, is probably a net positive.

      • jkrtn@lemmy.ml
        link
        fedilink
        arrow-up
        10
        arrow-down
        2
        ·
        2 months ago

        That attack surface is not vanishing. It’s would be relocating the same attack surface to something that might have an xz library in memory.

        • NekkoDroid@programming.dev
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          2 months ago
          1. The attack surface is there either way, this is just functionality repackaged that existed already before (systemd-run, which is calling into PID1)
          2. all compression libraries (actually most libraries at this point) are dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)