Re: kqueue EVFILT_PROC and child process pid
Re: kqueue EVFILT_PROC and child process pid
- Subject: Re: kqueue EVFILT_PROC and child process pid
- From: Terry Lambert <email@hidden>
- Date: Wed, 14 Oct 2009 06:20:09 -0700
On Oct 13, 2009, at 9:40 PM, Ryan McGann <email@hidden> wrote:
On Oct 13, 2009, at 12:08 PM, email@hidden
wrote:
On Oct 12, 2009, at 12:45 PM, Rustam Muginov wrote:
Thank you a lot for pointing up to the audit method.
I had found the "bsm" folder in the Mac OS X 10.5 SDK, looked
through the header files, but failed to find and documentation on
them so far.
P.S. I should have mentioned that /dev/auditpipe is not available
on
10.5 but currently only 10.6. Also, 10.5 doesn't have audit events
available for system calls like posix_spawn(). It seems that
posix_spawn() is used a lot by Mac OS X.
This is tagential, but still related, to another bug that we have
found, and already reported. It was present in 10.5 but not many
people used posix_spawn, but Apple uses it a lot more internally in
10.6. We tried to work around it, but it's proven more difficult
than originally thought.
Basically, we track all fileop_exec notifications to internally
watch processes being launched, but when posix_spawn is used, the
code path is slightly different (see xnu). For posix_spawn, the
fileop_exec notification is "posted" inside the context of the
parent process, not the child, making it impossible to tell what is
the new process ID.
rdar://problem/7244262
Summary:
When a KAUTH_SCOPE_FILEOP listener receives a KAUTH_FILEOP_EXEC
notification, there is no indication as to which process has loaded
the indicated executable. Calling proc_self() or proc_selfpid()
sometimes returns the loading process and sometimes returns the
parent of the process. (Unsure if there are any cases in which it
returns neither.)
Suggested enhancement:
When exec_activate_image() calls kauth_authorize_fileop() to
broadcast the KAUTH_FILEOP_EXEC notification, it passes zero as the
unused final argument to kauth_authorize_fileop(). At that point, it
also has information from which the desired BSD process could be
derived, so it could pass the proc_t pointer or the pid value for
the process as that final argument.
Not the same as the original problem stated here, but if the OP
wants to use a kernel extension, be warned that kauth_fileop_exec
won't work correctly in Snow Leopard either.
It works correctly, just not in the way you'd want it to work if your
intent was to inject code into each newly created process before it
got up and running. I am personally not a big fan of code injection of
this type, as it is inexact with regard to scheduling, at best. Better
that you use the spawn extensions yourself to start the child in a
suspended state with access to its task port directly.
There was never any guarantee that the notification for a posix_spawn
would happen in the context of the new process. Unlike exec, which
replaces the currently running process image, and thus current_proc()
returns a pointer to the process doing the replacing at the time if
the notification, unless you set the 'exec' flag in the spawn case,
the thread which is running at the time the spawn completes is the
parent process, not the child. The first time the child runs is
actually after we call thread_resume() on it and it gets sceduled into
user space, specifically into dyld, and we do not have an opportunity
to actually run any code in kernel space in the context of the new
process until it starts making system calls - which is way too late to
be effective.
We can (and do) hack the return value for current_proc() in the dtrace
probe point case, both for posix_spawn and for vfork/exec cases, but
NOT for the notification site, and for good reason; were you to
attempt instead current_task() or current_thread() rather than
current_proc(), you'd get the parents information instead. The dtrace
probe points are controllable code, so when we go through current_proc
(), we can know things will work; arbitrary KEXTs aren't controllable
by us so having a partially hooked up set of pointers is of limited
value if it makes it easy to make mistakes.
We have one extra pointer, and we have conflicting requests for it
use, including one that predates your request here. We have not
decided on a course of action at this time.
We are also limited on our binary compatibility guarantees to not
making a change in this area in minor releases; because of this you'd
have to check that the value was non-zero before using it, and if not,
fall back to using a heuristic, which would mean carrying around both
sets of code, so it's probably better to just carry around the
heuristic than introducing a variant code path in an update, when your
hueristic is going to have to work in case you are installed on a pre-
update system.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden