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.

  • corsicanguppy
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    2 days 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.

    • ricecake@sh.itjust.works
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      2 days ago

      Walk me through that analogy, and what point you’re trying to make. My hammer doesn’t typically have unexpected interactions with things I’m not hammering. When I build a bookshelf, I don’t have to make sure my desk is clean to keep people I let borrow books from unlocking my front door without a key.

      Do you think that improper setuid isn’t a common enough vulnerability to have a name and designation?

      What constitutes a security nightmare if not something that requires a large and annoying amount of work, and can be made insecure by a mistake somewhere else?