Every time I look at this, my conclusion is that sudo is a great tool for limiting coworker access and a terrible tool for limiting adversarial access.
This is one of those spots where "everything is a string" fails miserably. Sure, you can encode anything into a string, but that means your ACL system now needs to know how to decode all those formats. Or you do what we have now; regex and hope no one is clever enough to spot the bugs.
That's not even getting into the fact that shells can get input from all over. I.e. passing vars via stdin or variables.
Off the top of my head, you can open full root shells from basically any editor, I believe less can do it. You'll also have to ensure that none of the programs can crash to a debug REPL (i.e. if I can get a Python program to crash to a REPL, I can open bash or run my own Python as root).
I've always thought that sudo was almost totally useless.
One way or another it is going to be possible to exploit the permissions that are given to break out into a root shell.
As far as the idea that it "makes you think", given that I've absolutely typed it without thinking at all and rebooted prod, I'd say that's worthless as well.
Then there's all the silly tricks you need to learn in order to deal with shell redirection and handling of files that just get in the way of doing your job.
The only thing it does usefully is log all the commands executed, but you can hack up bash with honeypot logging patches to syslog every command executed and achieve the same thing.
There is a sort of narrow applicability of it so that you can grant some unprivileged operator the ability to run a script -- hopefully well audited with very limited number of knobs that it exposes -- to run with elevated privs. But the common use of it to give out access to nearly everything other than shell to system admin roles is pretty pointless and annoying.
Interactive `sudo` is good for awareness: "look, you are running this command with elevated privileges, unlike normal".
If an adversary got a shell with typical developer sudo access, the game is effectively over.
You can still use `sudo` with limited accounts to prevent escalation. Let such an account run under `sudo` only a fixed set of scripts which take no parameters, and which it cannot even read (but the privileged user can). Additionally, run them from within a chroot where only needed binaries are mapped. This may not stop the most sophisticated attacker, but will thwart a number of less-sophisticated.
This is one of those spots where "everything is a string" fails miserably. Sure, you can encode anything into a string, but that means your ACL system now needs to know how to decode all those formats. Or you do what we have now; regex and hope no one is clever enough to spot the bugs.
That's not even getting into the fact that shells can get input from all over. I.e. passing vars via stdin or variables.
Off the top of my head, you can open full root shells from basically any editor, I believe less can do it. You'll also have to ensure that none of the programs can crash to a debug REPL (i.e. if I can get a Python program to crash to a REPL, I can open bash or run my own Python as root).