The first thing. Invoked processes inherit the permissions of the user who invoked them (unless they have the setuid bit). It's just in case you land access to a computer which has all the standard Unix tools disabled to stop attackers from lateral movement.

▲

amiga386 4 hours ago | parent [-]

Why would you bother even doing that?

If someone has the power to execute commands, they are already on the other side of the airtight hatch.

https://devblogs.microsoft.com/oldnewthing/20240102-00/?p=10...

Put your meagre and limited resources on keeping them outside the hatch.

If they get through the hatch, that is where you fucked up, not that you didn't remove every conceiveable command from yourself should they get through. If they can remotely get some program to execute a shell, they can quite conceivably get the same program to just read them the files directly by writing different shellcode. Running a shell is just a convenience for them.

The number of setups that are insecure enough to allow remote shells by arbitrary attackers, but are secure because you disabled /bin/cat once they get in, is zero.

	▲	rithdmc an hour ago \| parent \| next [-]
		It's the principle of 'Defence in Depth'. Do both, as one control may fail.
	▲	dotancohen 3 hours ago \| parent \| prev \| next [-]
		Security is done in layers. Yes, we do our best to keep the adversaries outside the proverbial hatch. But even inside the hatch, the principal of least privilege is important in reducing the damage of attacks.
	▲	staticassertion 3 hours ago \| parent \| prev [-]
		Typically you do things like this to either work in restricted envs (distroless) or to evade detection logic. It's not about bypassing a boundary, it's about getting things done in the env you have available.