Explanation for newbies: setuid is a special permission bit that makes an executable run with the permissions of its owner rather than the user executing it. This is often used to let a user run a specific program as root without having sudo access.

If this sounds like a security nightmare, that’s because it is.

In linux, setuid is slowly being phased out by Capabilities. An example of this is the ping command which used to need setuid in order to create raw sockets, but now just needs the cap_net_raw capability. More info: https://unix.stackexchange.com/questions/382771/why-does-ping-need-setuid-permission. Nevertheless, many linux distros still ship with setuid executables, for example passwd from the shadow-utils package.

  • tal@lemmy.today
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    1 month ago

    If this sounds like a security nightmare, that’s because it is.

    You can perfectly-reasonably implement suid binaries securely. They need to be simple and carefully constructed, and there shouldn’t be many of them, but the assertion that suid is “a security nightmare” is ridiculous. sudo itself relies on the suid bit.

    • ricecake@sh.itjust.works
      link
      fedilink
      arrow-up
      9
      ·
      1 month ago

      I would describe need to proactively go out of your way to ensure a program is simple, minimal, and carefully constructed to avoid interactions potentially outside of a restricted security scope as a “security nightmare”.

      Being possible to do right or being necessary in some cases at the moment doesn’t erase the downsides.

      It’s the opposite of secure by default. It throws the door wide open and leaves it to the developer and distro maintainer to make sure there’s nothing dangerous in the room and that only the right doors are opened. Since these are usually not coordinated, it’s entirely possible for a change or oversight by the developer to open a hole in multiple distros.
      In a less nightmarish system a program starting to do something it wasn’t before that should be restricted is for the user to get denied, not for it to fail open.

      https://www.cve.org/CVERecord/SearchResults?query=Setuid

      It may be possible, but it’s got the hallmarks of a nightmare too.

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

        Hard agree. This is why rust is getting so much attention, and the c/c++ crowd are so mad. They’re happy just blaming it on a “skill issue” while losing their shit over [the rust crowd] saying “how about we don’t let you in the first place.”

      • corsicanguppy@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 month ago

        need to proactively go out of your way to ensure a program is simple, minimal, and carefully constructed to avoid interactions potentially outside of a restricted security scope as a “security nightmare”.

        You must fear hammers.

    • renzev@lemmy.worldOP
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      1 month ago

      They need to be simple and carefully constructed

      Yeah, that’s the difficult part. It’s always better to go with the principle of least privilege (which is Capabilities is trying to do) than to just cross your fingers and hope that there are not bugs in your code. And who exactly is going to police people to make sure that their programs are “simple and carefully constructed”? The article I linked is about a setuid-related vuln in goddamn Xorg which is anything but.