upvote

points

by dominicq6 hours ago |
comments
upvoteby amiga3863 hours ago|
[-]
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.

reply
upvoteby rithdmc1 hours ago|
parent|
next
[-]
It's the principle of 'Defence in Depth'. Do both, as one control may fail.
reply
upvoteby dotancohen2 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.
reply
upvoteby staticassertion3 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.
reply