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: Rustam Muginov <email@hidden>
- Date: Mon, 12 Oct 2009 21:45:07 +0400
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.
The only docs i found are the Common Criteria manuals about command-
line tools and GUI apps here:
http://www.apple.com/support/security/commoncriteria/
Are where any examples/code snippets available?
I do believe i could use the audit facility from inside my appliction,
instead of relying on external command-line tools.
Should the process dealing with audit run on behalf of root, or it
could be a regular user process?
Thank you in advance.
On Oct 12, 2009, at 7:06 PM, Stacey Son wrote:
On Oct 12, 2009, at 2:20 AM, Jean-Daniel Dupas wrote:
Le 12 oct. 2009 à 01:01, Stacey Son a écrit :
On Oct 11, 2009, at 3:01 PM, Dave Keck wrote:
As far as getting the the new child's PID, I don't think it's
possible
using the kevent APIs from userland. (sys/event.h mentions "lower
bits
contain the PID of the child", but I think this is kernel-only.)
FWIW:
This depends on which version of Mac OS you are using... Before
10.5 I believe you could use NOTE_TRACK and NOTE_CHILD to get the
PID of the child. The PID of the child would be stored in the
ident field and the PID of the parent (aka. PPID) would be stored
in the data field. I guess this is no longer the case. See sys/
event.h:
/*
* DEPRECATED!!!!!!!!!
* NOTE_TRACK, NOTE_TRACKERR, and NOTE_CHILD are no longer
supported as of 10.5
*/
Best Regards,
The last time I tried to used them is a simple application, it was
triggering a Kernel Panic, until Apple fix that by returning
ENOTSUP when trying to register an event with theses flags.
I never saw a version of OS X that support it.
This explains why these flags were deprecated. :)
Another way to monitor and get the PID of new processes is to use
auditing. See the FreeBSD documentation for the details: http://www.freebsd.org/doc/en/books/handbook/audit.html
In short, you could audit the fork() and posix_spawn() system call
events. The child PIDs are given as arguments to these events. To
do this you will need to add the "process" audit class ("pc") to the
"flags" and "naflags" fields of /etc/security/audit_control (or
better yet, create your own audit class with just these events*) and
restart auditing by doing "sudo audit -s" (or rebooting). You can
then read the events from either the audit trail files in /var/audit
or by reading /dev/auditpipe (see "man auditpipe"). This assumes
you are running 10.6.
Of course, auditing system call events can add some overhead. To
reduce this overhead as much as possible you may want to create a
new audit class with just the system events you would like to
audit. This is done by edit the /etc/security/audit_class and /etc/
security/audit_event files (see 'man audit_class' and 'man
audit_event').
Best Regards,
-stacey.
--
Sincerely, Rustam Muginov
_______________________________________________
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