[antientropic]

This is what happens when a new security model is retrofitted onto an existing one.

In the original Unix security model, there was no security concern with this (except maybe for chroot environments): it didn't allow a process to do something it couldn't otherwise do, since all processes owned by a uid had exactly the same rights. Now that we've started sandboxing user processes in various ways on macOS and Linux, that's no longer the case, and we suddenly need to crack down on useful tools like strace and gdb.

[noduerme]

Sorry... this is above my pay grade, but I still think of processes as running on a single thread, reserving memory and being mostly inviolable other than maybe sampling what they're holding at the moment. How does giving a tool the ability to analyze a thread allow it to inject code into the process as it's running? Forgive me if I'm just way behind but isn't the kernel of any modern OS supposed to prevent exactly that thing from happening?

[korfuri]

A lot of legitimate debugging features involve actually modifying the code of the target. This is a common way of setting breakpoints: you replace the instruction at the given address with a trap instruction that will hand control back to the debugger. Then the debugger puts the original instruction back and resumes the target's execution.

And since the two processes already run as the same user, in the original model there's nothing the target can do that the debugger cannot also do, so this was not a privilege escalation path.