site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 14, 2009, at 6:20 AM, Terry Lambert 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. 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. Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Oct 13, 2009, at 9:40 PM, Ryan McGann <rmcgann@mac.com> wrote: On Oct 13, 2009, at 12:08 PM, darwin-dev-request@lists.apple.com wrote: 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. 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. This email sent to site_archiver@lists.apple.com