Re: Process Termination Detection
Re: Process Termination Detection
- Subject: Re: Process Termination Detection
- From: Terry Lambert <email@hidden>
- Date: Sat, 15 Nov 2008 05:22:05 -0800
task_for_pid() does not behave as you describe; it will also work if
you have equivalent credentials.
This sounds like an "adjacent square" security attack, since you don't
have normal task_for_pid() privileges by virtue of credential
equivalence, and you don't have escalated monitoring or debugging
privileges, either of which are required for your program to have
legitimate rights to the information it wants.
In general, there are not really any non-polled methods that do not
require some form of privilege or equivalence of identity to get this
information. This includes but is not limited to:
- the process consents to being monitored and actively participates by
establishing an IPC channel for which disconnect notifications will be
sent to the monitoring program
- the system consents to the monitoring because of privilege
escalation by the monitoring program, or because of credential
equivalence with the monitored program combined with constrained
capabilities of the monitor API
- standards compliance requires the ability to obtain such information
(which is why kill-polling and polled parseing "ps" output would
work), despite security considerations to the contrary
There is, of course, always opportunistic monitoring, but that takes a
little more detailed knowledge of the programs behaviour:
- the program itself has voluntary "tells" which an be used as a
covert monitoring method... e.g. It deletes a publically visible data
file on exit, it keeps a publically visible file open until it is
resource tracked closed, it logs to a publically visible log file that
it is exiting, it has a known rendezvous such as a posix shared memory
path, a system V IPC ID, etc.. In general, utilizing many, but not
all, of these methods will also require polling.
Maybe you can tell us a little bit more about the program you are
trying to attack, and why knowing that it has exitted will facilitate
your attack, and how narrow a time window you believe you have before
the attack would fail, and we could help you narrow things down.
-- Terry
On Nov 14, 2008, at 2:11 PM, Brian McKinnon <email@hidden>
wrote:
I am trying to find the best solution to the following problem. I
would like to have process A be able to determine when process B has
terminated. Process B does not necessarily have to be a child of
process A. Any solutions in the mach, POSIX, BSD, Carbon or Cocoa
layers would be considered.
The two solutions I have found so far are as follows.
Solution 1:
API: Posix
Poll using kill( pid, 0 ) and wait for an ESRCH error indicating
that there is no process with the id 'pid'. This solution is not
good because it requires frequent poling for the life of process B
which may be long lived. It has the benefit that no special
privileges are needed to execute it.
Solution 2:
API: mach
Use task_for_pid( myTask, pid, &task ) to get a port on process B.
Use mach_port_request_notification( myTask, task,
MACH_NOTIFY_DEAD_NAME, 1, port, MACH_MSG_TYPE_MAKE_SEND_ONCE,
&lastPort) to register a notification on the mach port 'port' when
the mach port 'task' becomes a dead name. The drawbacks to this
solution are that process A needs to be running as root, be in the
group procmod or be digitally signed. It has the benefit that no
polling is required.
Are there any other solutions to this on Darwin?
_______________________________________________
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