okay, this `please` program is rather bad, and the fix for CVE-2021-31153 is laughably wrong.
Conversation
Replying to
It doesn't appear they did basic research into the required security model for setuid/setgid/setcap binaries.
It's pretty unfortunate since they do seem to care about security but were totally clueless about it and made a LOT of obvious mistakes beyond just setuid-specific ones.
1
5
I don't understand how they ended up in the situation where they were writing a privilege escalation tool shipped by multiple Linux distributions. Some of the issues like the /tmp races are well known things not at all specific to the whole legacy setuid/setgid/setcap approach.
Replying to
they've been submitting their program for inclusion to multiple Linux distributions! void, arch and alpine so far have NAKed it. debian and suse seem to have accepted it.
2
Replying to
I've rarely heard of developers going out of the way to get their program included in a bunch of distributions. I didn't realize requesting package inclusion was even a thing in distributions beyond Debian. I don't really think it's a thing for Arch beyond annoying mailing lists.
As with sudo, it's largely just a way to mislead yourself into thinking users aren't root equivalent. The focus on regex-based rules is a really bad idea.
CLI tools are not generally written with the threat model that they're enforcing a security boundary and can't trust args.
1
4
If the goal is for your own user account to not have root access while having it yourself, then logging in directly as root is the way to go. SSH as root for a server or logging in as root via virtual console locally. Escalating to root from a user just makes them equivalent...
1
2