You are only browsing one thread in the discussion! All comments are available on the post page.

Return

jet ,

But with one key difference: it's *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user's UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).

aleph ,
@aleph@lemm.ee avatar

I understood some of those words...

intrepid ,

Unfortunately, this is about as easy as it gets. Practically though, it isn't going to matter. It sounds like run0 will be a drop-in replacement for sudo. We will know for sure in about 3 days (at the rate at which they assimilate features).

aleph ,
@aleph@lemm.ee avatar

So there would be no practical benefits of switching?

hunger ,
@hunger@programming.dev avatar

It gets rid of one more SUID binary. That's always a win for security.

Sudo probably is way more comfortable to use and has way more configurable, too -- that usually does not help to make a tool secure either:-)

kbotc ,

While it may be true that getting rid of SUID binary is ideal, widening systemd’s security surface area is much more concerning to me than the sudo binary.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • opensource@lemmy.ml
  • random
  • All magazines