I had the "joy" of watching some guys from Perforce setup a new p4 instance.<p>They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening".<p>It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allows you to give e.g. the Python interpreter CAP_SETUID, making a privilege escalation to root trivial again.
Loopholes of this kind exist these days as well.<p>When I was working for a major retailer, who, you'd assume would have thought about these things well enough, you were prevented from executing sudo, except for being able to use it for text editing (sudo vi). I needed to install some packages with a root shell at the time, so I used the command execution feature within vi to get that.
Setting aside all of the technical aspects of this, the history of this in the world of UNIX, I just love the process and bureaucracy that generated this specific paper document. The very formal cover sheet (and the fact that it had an accompanying, separate, numbered instruction document), the pre-determined layout and format of a Technical Memorandum, and the fact that this was published as such a memorandum with filing and control numbers that will be researched and looked up in a library instead of just a blog or post on Medium<p>We used to be a real society
> <i>They did not invent UNIX but they try harder</i><p>I fear that this reference to an old Avis advertising slogan may be lost to a modern audience.
It's the same today, only it's webapps instead of unix utilities. Simplest bugs in the world, still devs don't pay attention to them. Simple like not sanitizing inputs, injecting stuff straight into sql queries or exec commands, dumping customer data / passwords / all environment variables into logs and error messages, etc.