I'm not quite sure what you're trying to accomplish, but I'm pretty sure
that you're doing it wrong. Checking that the process being invoked is
/usr/bin/utility instead of /Users/ben/utility won't help if the action
you're scanning for can be carried out by /usr/bin/utility - either
intentionally or due to a flaw in how the utility is written. And there
are numerous methods that can be used from an ordinary user account to
cause a process running as that user to execute arbitrary code. If
executable path-based protection is central to your anti-malware
product, your product won't be much of a problem for malware authors at all.
What I'm trying to do is enable excludes from the KEXT operation.
I'm deploying a network traffic filter that consists of an NKE and
a user space process, that is performing the filtering.
Unfortunately, the way this can be done on Mac OS X is only to redirect
the connection to user space and create a separate connection from there.
The data can't be scanned on the fly unless it is done non-blocking in the
NKE itself. See the "Socket Filter NKE" mailing thread for details.
It works basically like this: NKE is redirecting traffic to FILTER. Any
connection initiated from the FILTER is not redirected as the FILTER
is registered in NKE and has an exception. This exception is based
on the FILTER doing some special calls to let NKE know about it.
The problem is, that any other software trying to do the same will
cause packet loops and exhaust system resource in time.
I can either document it, or allow users to specify an exception telling that
this specific software should be excluded from the redirection mechanism,
so he can keep them both. But I do not wont these excludes to be too general
as anyone can than easily bypass the filter.
I know it is rather corner-case situation, but I think it could be useful. Another
point is. Isn't it just unlucky decision to let user-space utilities like lsof get access
to more details about processes then when you are directly in the kernel??