9 ms·

> 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,

> 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). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn't have all the permissions it needs, so you add "sudo" as an adverb. Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in. And sometimes the thing you're running is a complicated shell script or shell-script-like object, eg "sudo make install". In this case, you don't really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it'll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags. And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.

yorwba 2y ago
I don't know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables. The thing you're saying is going to be an endless source of problems should already be an endless source of problems! (And I think I've been briefly confused by some missing environment variable once or twice so far.)
- mid-kid 2y ago
  It depends on whether sudo was compiled with --disable-env-reset or not, it's on by default[1]. Also some variables are inherited regardless (e.g. DISPLAY, TERM), and some useful ones (e.g. HOME) are initialized by sudo, but I can't tell where that's done. [1]: https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ffd2e8893f1ef65f5b0fc014/configure.ac#L1279 https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ff...
- crabbone 2y ago
  Even without the flag, sudo preserves a bunch of stuff. And it's not even consistent. Some implementations preserve locale setting, while others don't for example.
  - 0x457 2y ago
    It depends on what options sudo us built with. Notably `--disable-env-reset` option.
lyu07282 2y ago
I think what is perhaps something to consider is how much of an attack surface sudo is and how unaware people are of the fact. Many people think they can configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it. But they don't realize all the ways it can be abused for privilege escalation. Getting rid of all that configuration removes that false sense of security, which is a good thing, it has been a huge footgun in Linux for decades. Some incompatibility is price well worth paying for that imho
- lupusreal 2y ago
  I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user, I've only ever seen cases where the use of sudo is unrestricted albeit logged. Where are these organizations where developers or syaadmins are allowed to use sudo but only with white listed commands? I don't doubt that some people are doing this, I just think it's not common. Replacing the whole of sudo with some weird new thing to better support a niche usecase seems disconnected from reality to me.
  - sapphire_tomb 2y ago
    My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.
    - WesolyKubeczek 2y ago
      Not even using "su" as become_method? Granted, it would require the root's password, so it's another tradeoff, but...
    - 2y ago
keepamovin 2y ago
Yeah we had to explicitly set that to No and enable linger to let pulseaudio keep running for users so they can continue to stream sound from their remote browsers in BrowserBox/CloudTabs. Ie at: https://puter.com/app/cloudtabs-browserbox https://puter.com/app/cloudtabs-browserbox Your comment was really well expressed btw. Made your thoughts and emotions very clear about this. Inspiring communication skill! :)
throw0101b 2y ago
> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. See for example perhaps, "systemd can't handle the process previlege that belongs to user name starts with number, such as 0day": * https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Never mind that POSIX allows it: * https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_426 https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd... * https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276 https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd... > I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later. For anyone curious, see "Systemd v230 kills background processes after user logs out, breaks screen, tmux" from 2016: * https://news.ycombinator.com/item?id=11782364 https://news.ycombinator.com/item?id=11782364
bayindirh 2y ago
> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along. Systemd: Do all the things, but not very well, and don’t listen to anyone.
- lyu07282 2y ago
  I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?
  - datadrivenangel 2y ago
    SUID has flaws, but it's not clear that there are any more convenient alternatives?
    - 1oooqooq 2y ago
      you missed the memo. it's dbus. (wish i could end with /s)
    - semi 2y ago
      it depends on what you're needing suid for but the first thing id evaluate is if you can just grant a specific CAPAB instead.
  - bayindirh 2y ago
    SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems. Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture. Moreover, removing SUID breaks tons of mechanisms and scenarios. Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be. When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with. XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?
KWxIUElW8Xt0tD9 2y ago
One binary to rule them all, one binary to find them, one binary to bring them all and in the darkness bind them; in the Land of Lennart where the shadows lie. Bwaahahaha.
- Aerbil313 2y ago
  This gave me a genuine chuckle. Clever humor, thank you.
sigil 2y ago
run0 has already been exploited: https://twitter.com/hackerfantastic/status/1785495587514638559 https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.
- sfink 2y ago
  Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it. I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg doesn't fit in the round hole, then he'll always say that the peg is perfect and the world just needs to chisel out the corners of the hole.
  - sigil 2y ago
    What do you mean by "great ideas and great implementation / bad execution and bad interface." Is this a plumbing vs porcelain distinction?
    - sfink 2y ago
      Yes? Well, partly. For systemd and pulseaudio, the systems they were replacing legitimately had major problems. There were variants and workarounds that fixed some of these, but no holistic solution that I've ever heard of. There were just so many limitations if you maintained any degree of compatibility. People were (understandably) unwilling to start over and rearchitect something that desperately needed rearchitecting. Poettering designed and implemented replacements that were substantially better, and worked. Worked well, in fact. That's the great ideas & implementation part. Much of this was enabled by a willingness to throw out compatibility with nearly everything. Backwards, forwards, sideways. If I were making a bold and breaking change like this, I would sacrifice compatibility but try to make up for it by bending over backwards to catch as much of the "once working, now broken" wreckage that inevitably piled up as I could, by creating shims and compatibility stubs and transition mechanisms. I'd certainly listen to people's problems and try to work out solutions. Poettering, as far as I can tell is more of a honey badger (excuse the dated meme). He just doesn't give a shit. If your stuff doesn't work in the brave new world, then your stuff is broken and is going to have to adapt. That's the bad execution part. (Which is not to say that bending over backwards is always the right approach; it can massively increase the burden on the new system's implementer, to the point that it never happens. There's a reason why Poettering's stuff is taking over the world.) As for bad interface, this is a lot more subjective, so it's easier to disagree. But the tools to configure and use the new system are done in the style of an isolated cathedral. The tools do a ton of stuff, but they do it all in a new way, and that's great once you learn the blessed paths and internalize the new architecture. But all of your existing knowledge is now useless, and you can't flexibly combine and extend the functionality with the usual tools you'd use (bash, grep, awk, find, sort, tee....) The main functionality of the new system is not new — none of this is really adding fundamental new capabilities, it's just improving things that were already being done. But the way you interface with that functionality is all new, even though it could have been exposed in ways at least a little more unix-like and composable. Instead, the tool author determines all the things you should be doing and gives you a way to do them. If you want more or different, then you're doing something wrong. Normally, I'd expect something like this to die out as it rubbed up against the surrounding functionality. "Great system, but too much effort when we keep having to fix thing after thing." Surprisingly (to me), in systemd's case in particular, what has actually happened is that the cathedral just keeps expanding to swallow up enough of its surroundings to keep from being ejected. Maybe it's sour grapes, but my guess is that this was only possible because the previous systems were so bad. esd was a nightmare. sysvinit scripts were baroque and buggy and error-prone. Sure, the first 80% was just plain simple shell scripting. But everything did the last 20% slightly differently or just punted. It was all buggy and idiosyncratic and failed intermittently. Supposedly some of the init system variants managed to corral it all together enough to do actual dependencies and get decent startup speed, but I never used such a system. And based on the quality of the init scripts I've seen from random packages, I'm guessing the successes only happened when a relatively small group of people wrote or repaired a metric shitload of init scripts by hand. And even then, systemd provides more in its base functionality set. Architecturally, it's really quite nice.
runiq 2y ago
The way I see it, this is actually a good thing. Superuser access should impose a tiny bit of friction in this regard, to enforce discipline where discipline is warranted. Run0 builds character. :^)

yorwba 2y ago

I don't know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables. The thing you're saying is going to be an endless source of problems should already be an endless source of problems! (And I think I've been briefly confused by some missing environment variable once or twice so far.)

mid-kid 2y ago
It depends on whether sudo was compiled with --disable-env-reset or not, it's on by default[1]. Also some variables are inherited regardless (e.g. DISPLAY, TERM), and some useful ones (e.g. HOME) are initialized by sudo, but I can't tell where that's done. [1]: https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ffd2e8893f1ef65f5b0fc014/configure.ac#L1279 https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ff...
crabbone 2y ago
Even without the flag, sudo preserves a bunch of stuff. And it's not even consistent. Some implementations preserve locale setting, while others don't for example.
- 0x457 2y ago
  It depends on what options sudo us built with. Notably `--disable-env-reset` option.

lyu07282 2y ago

I think what is perhaps something to consider is how much of an attack surface sudo is and how unaware people are of the fact. Many people think they can configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it. But they don't realize all the ways it can be abused for privilege escalation. Getting rid of all that configuration removes that false sense of security, which is a good thing, it has been a huge footgun in Linux for decades. Some incompatibility is price well worth paying for that imho

lupusreal 2y ago
I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user, I've only ever seen cases where the use of sudo is unrestricted albeit logged. Where are these organizations where developers or syaadmins are allowed to use sudo but only with white listed commands? I don't doubt that some people are doing this, I just think it's not common. Replacing the whole of sudo with some weird new thing to better support a niche usecase seems disconnected from reality to me.
- sapphire_tomb 2y ago
  My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.
  - WesolyKubeczek 2y ago
    Not even using "su" as become_method? Granted, it would require the root's password, so it's another tradeoff, but...
  - 2y ago

keepamovin 2y ago

Yeah we had to explicitly set that to No and enable linger to let pulseaudio keep running for users so they can continue to stream sound from their remote browsers in BrowserBox/CloudTabs. Ie at: https://puter.com/app/cloudtabs-browserbox https://puter.com/app/cloudtabs-browserbox Your comment was really well expressed btw. Made your thoughts and emotions very clear about this. Inspiring communication skill! :)

throw0101b 2y ago

> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. See for example perhaps, "systemd can't handle the process previlege that belongs to user name starts with number, such as 0day": * https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Never mind that POSIX allows it: * https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_426 https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd... * https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276 https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd... > I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later. For anyone curious, see "Systemd v230 kills background processes after user logs out, breaks screen, tmux" from 2016: * https://news.ycombinator.com/item?id=11782364 https://news.ycombinator.com/item?id=11782364

bayindirh 2y ago

> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along. Systemd: Do all the things, but not very well, and don’t listen to anyone.

lyu07282 2y ago
I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?
- datadrivenangel 2y ago
  SUID has flaws, but it's not clear that there are any more convenient alternatives?
  - 1oooqooq 2y ago
    you missed the memo. it's dbus. (wish i could end with /s)
  - semi 2y ago
    it depends on what you're needing suid for but the first thing id evaluate is if you can just grant a specific CAPAB instead.
- bayindirh 2y ago
  SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems. Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture. Moreover, removing SUID breaks tons of mechanisms and scenarios. Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be. When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with. XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?

KWxIUElW8Xt0tD9 2y ago

One binary to rule them all, one binary to find them, one binary to bring them all and in the darkness bind them; in the Land of Lennart where the shadows lie. Bwaahahaha.

Aerbil313 2y ago
This gave me a genuine chuckle. Clever humor, thank you.

sigil 2y ago

run0 has already been exploited: https://twitter.com/hackerfantastic/status/1785495587514638559 https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.

sfink 2y ago
Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it. I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg doesn't fit in the round hole, then he'll always say that the peg is perfect and the world just needs to chisel out the corners of the hole.
- sigil 2y ago
  What do you mean by "great ideas and great implementation / bad execution and bad interface." Is this a plumbing vs porcelain distinction?
  - sfink 2y ago
    Yes? Well, partly. For systemd and pulseaudio, the systems they were replacing legitimately had major problems. There were variants and workarounds that fixed some of these, but no holistic solution that I've ever heard of. There were just so many limitations if you maintained any degree of compatibility. People were (understandably) unwilling to start over and rearchitect something that desperately needed rearchitecting. Poettering designed and implemented replacements that were substantially better, and worked. Worked well, in fact. That's the great ideas & implementation part. Much of this was enabled by a willingness to throw out compatibility with nearly everything. Backwards, forwards, sideways. If I were making a bold and breaking change like this, I would sacrifice compatibility but try to make up for it by bending over backwards to catch as much of the "once working, now broken" wreckage that inevitably piled up as I could, by creating shims and compatibility stubs and transition mechanisms. I'd certainly listen to people's problems and try to work out solutions. Poettering, as far as I can tell is more of a honey badger (excuse the dated meme). He just doesn't give a shit. If your stuff doesn't work in the brave new world, then your stuff is broken and is going to have to adapt. That's the bad execution part. (Which is not to say that bending over backwards is always the right approach; it can massively increase the burden on the new system's implementer, to the point that it never happens. There's a reason why Poettering's stuff is taking over the world.) As for bad interface, this is a lot more subjective, so it's easier to disagree. But the tools to configure and use the new system are done in the style of an isolated cathedral. The tools do a ton of stuff, but they do it all in a new way, and that's great once you learn the blessed paths and internalize the new architecture. But all of your existing knowledge is now useless, and you can't flexibly combine and extend the functionality with the usual tools you'd use (bash, grep, awk, find, sort, tee....) The main functionality of the new system is not new — none of this is really adding fundamental new capabilities, it's just improving things that were already being done. But the way you interface with that functionality is all new, even though it could have been exposed in ways at least a little more unix-like and composable. Instead, the tool author determines all the things you should be doing and gives you a way to do them. If you want more or different, then you're doing something wrong. Normally, I'd expect something like this to die out as it rubbed up against the surrounding functionality. "Great system, but too much effort when we keep having to fix thing after thing." Surprisingly (to me), in systemd's case in particular, what has actually happened is that the cathedral just keeps expanding to swallow up enough of its surroundings to keep from being ejected. Maybe it's sour grapes, but my guess is that this was only possible because the previous systems were so bad. esd was a nightmare. sysvinit scripts were baroque and buggy and error-prone. Sure, the first 80% was just plain simple shell scripting. But everything did the last 20% slightly differently or just punted. It was all buggy and idiosyncratic and failed intermittently. Supposedly some of the init system variants managed to corral it all together enough to do actual dependencies and get decent startup speed, but I never used such a system. And based on the quality of the init scripts I've seen from random packages, I'm guessing the successes only happened when a relatively small group of people wrote or repaired a metric shitload of init scripts by hand. And even then, systemd provides more in its base functionality set. Architecturally, it's really quite nice.

runiq 2y ago

The way I see it, this is actually a good thing. Superuser access should impose a tiny bit of friction in this regard, to enforce discipline where discipline is warranted. Run0 builds character. :^)