Hacker News new | ask | show | jobs
by antientropic 1402 days ago
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.
1 comments
noduerme 1402 days ago
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?
link
korfuri 1402 days ago
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.

link
noduerme 1402 days ago
If you're debugging as the same user that makes sense because the debugger is supervising the code. (the debugger can't for example halt other processes besides the code it's supervising). But how can some other random process even with the same user just inject itself into running compiled code without somehow having the ability to rewrite memory? [edit: memory that has already been allocated by the kernel for the thread it's trying to interfere with]
link
hmage 1402 days ago
The difference between debugger and non-debugger in 80's unix is... none, besides calling ptrace().

I called ptrace() on your pid, therefore I am your debugger now.

link