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: Ryan McGann <email@hidden>
- Date: Wed, 14 Oct 2009 09:41:25 -0700
On Oct 14, 2009, at 6:20 AM, Terry Lambert wrote:
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.
We're not trying to inject, just trying to monitor. In fact, we don't
really need the notification at all, except for the fact that the KPIs
have no way to obtain a vnode or path pointer from a pid_t. The
kauth_fileop_exec was added at our request during an Apple KPI kitchen
as a workaround for the lack of a pid_t -> vnode mapping. We need that
mapping for a variety of reasons that Apple acknowledged were desired
by both us and other 3rd parties, as well as some within Apple itself.
But the kernel still lacks it, so we have a very complex IOKit kernel
extension that just sits there, watching for fileop_open, fileop_close
and fileop_exec notifications so we can try and maintain the mapping
ourself (has to be IOKit so it can set the OSBundleRequired == Root
flag in its Info.plist).
It's a huge kludge, and one we want to avoid, but until rdar://problem/
3751262 is addressed, it's the only choice we have. The kludge gets
even bigger with Snow Leopard, so that we can address posix_spawn,
which is where this issue came up. Since we have to do the pid lookup
in-kernel, the auditing facilities and kqueue are not a viable option
for us.
Ryan
_______________________________________________
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