A process can't change the address space of another process, period. Even if one is a root process. Separation of address spaces is a basic security service provided by the operating system. So I'm also puzzled how they are able to modify memory in Finder's address space.
The closest thing I can think of is that Finder executes arbitrary processes on behalf of the user. That is, when I double click on something, Finder has to do the fork-exec dance to launch that application. A process fork, however, creates an entirely separate address space for the new process. I would be shocked if Finder did not do that. So, yes, I'm also wondering what it is they do.
The first chunk of those slides talk about library hijacking. Say, you define your own version of malloc, make sure the application links to your version of malloc, and play your tricks from there. Process isolation has not been violated.
Slide 4 is the difference: OSX is BSD running on top of Mach. So these techniques use the Mach layer to get around basic process protection. This is terribly insecure.
> A process can't change the address space of another process, period. Even if one is a root process. Separation of address spaces is a basic security service provided by the operating system. So I'm also puzzled how they are able to modify memory in Finder's address space.
Sure you can. Every major PC OS (Windows, Mac, Linux) has a debugging API that, in fact, does allow you to read and write the memory of other processes. Windows even has a convenient function to allocate blocks of memory in other processes' address space, and another function to spawn a thread in another process with an arbitrary entry point - which makes this sort of thing relatively easy to do.
Mind you, the primitives provided can be a bit difficult to work with, but it's far from impossible.
> A process can't change the address space of another process, period. Even if one is a root process. Separation of address spaces is a basic security service provided by the operating system.
That is not even close to true, on any operating system.
I had, but that's not the situation I had in mind. You can only use ptrace on a child process. You can't use ptrace to attach to, say, another user's process.
You can attach to any of your processes, that's how debuggers work! Ever used gdb to attach to a running process and debug it on the fly? This is done with ptrace() with the PT_ATTACH flag.
The closest thing I can think of is that Finder executes arbitrary processes on behalf of the user. That is, when I double click on something, Finder has to do the fork-exec dance to launch that application. A process fork, however, creates an entirely separate address space for the new process. I would be shocked if Finder did not do that. So, yes, I'm also wondering what it is they do.