See also the sudo bad environment variable list[1], which I recently found a 15 year old typo in.[2]
[1]: https://github.com/sudo-project/sudo/blob/master/plugins/sud... [2]: https://www.sudo.ws/repos/sudo/rev/bdf9c9e7f455
[1]: https://github.com/sudo-project/sudo/blob/master/plugins/sud... [2]: https://www.sudo.ws/repos/sudo/rev/bdf9c9e7f455
I mean, good intentions, should've worked, but a single mistake wasn't discovered among all of the features involved in locking it down as hard as possible.
Security is a fight nobody can win, because it's an N-1 relationship of reassuring your own mistakes vs. finding a single mistake as an opportunity.
I mean look at those variables, this seems like a loosing battle. PERLLIB, PERL5LIB etc. - what if there's a PERL6LIB at some point or a NEWSCRIPTINGLANGUAGELIB variable?
The list is still relevant to this discussion though as a nice "greatest hits" cheat-sheet of fun environment variables to play with here.
I think that the fail-close design (I know them as positive-style branching) should be embraced everywhere possible.
But can this be actually achieved without breaking the ecosystem in the sense of having to start all over again?
Unless you're fuzzing, automated testing could've easily missed this.