Apple

On Tue, Jul 19, 2016 at 9:29 AM, Luigi Vampa <email@hidden> wrote:

(Reposting, with slight rephrasing, my post on an different forum...)

So it turns out the famous EXEC handler in KAUTH_SCOPE_FILEOP behaves very differently when called from execve() as opposed to being called from posix_spawn()...
When the KAUTH callback is called from standard 'execve' (the intuitive) case, it is called from the child's process context.
But when the callback is triggered via 'posix_spawn()', is called from the *parent* process context...
So the PID I get in the callback in the latter case is of the parent.

This means that if I want to do some proc/mem analysis from within this callback, I cannot do it if a process was created via posix_spawn().
In addition, there appears to be no handler (MAC, KAUTH or otherwise) which can be used to intercept a child process in such a way that I have time to do some analysis thereof...

This is a very surprising and (seemingly) inconsistent behavior of the callback. I wonder if this is by design...
Any ideas? At the very least, any ideas how to get the PID of the child process from the KAUTH callback after being called from posix_spawn()?

If you're OK with using the (unsupported) MAC framework, here are some observations which should allow you to come up with a satisfactory work-around:

1. The mpo_cred_label_associate_fork MAC policy ops callback is called when launching a process via posix_spawn(), and the proc_t argument is the child process.

2. mpo_cred_label_associate_fork is of course also called when you directly invoke fork(), and it's not clear from within the callback function which syscall is responsible.

3. KAUTH_SCOPE_FILEOP with an action of KAUTH_FILEOP_EXEC is called on the same thread as the MAC fork callback when they are triggered by a posix_spawn(), i.e. current_thread() will return the same thread_t.

4. When posix_spawn runs, the fork callback happens before the exec.

5. The pairing of the mac_schedule_userret() function and mpo_thread_userret callback is very handy for cleaning up "syscall-local" state in a global data structure.

Putting this together, you can reliably detect a posix_spawn() call and get the child PID:

- In the mpo_cred_label_associate_fork callback, associate the current thread with the child process's PID in some global data structure, then call mac_schedule_userret().

- In the KAUTH_SCOPE_FILEOP, KAUTH_FILEOP_EXEC action handler, look up the current thread in the global data structure. If you find it, this is a posix_spawn call and you now have the child PID. If not, it's a direct exec*() call, and the current process is already the "child" process.

- In the mpo_thread_userret, remove the current thread from the data structure, if it's there.

This may or may not be enough for what you're trying to do, but it should hopefully get you closer.

Phil

References:
	>posix_spawn() and the KAUTH_FILEOP_EXEC action (in KAUTHs' 'FILEOP' scope) (From: Luigi Vampa <email@hidden>)
	>Re: posix_spawn() and the KAUTH_FILEOP_EXEC action (in KAUTHs' 'FILEOP' scope) (From: Phil Dennis-Jordan <email@hidden>)