How are we supposed to get the pid from a NEFilterFlow?

Please note I have already seen the answers pointing to the audit_token.

From what I'm observing, the audit_token does not return the pid from a NEFilterFlow but actually returns the epid.

For instance, if Safari is sending a HTTP GET request and the server name of the URL needs to be resolved, mDNSResponder will resolve the URL on behalf of Safari.

In this case, the debug info for the NEFilterFlow shows that:

  • the procPID for the flow representing the UDP communication to port 53 is the one of mDNSResponder.
  • the eprocPID for this flow is the one of Safari.

If you use the audit_token of the sourceApp, you will end up with the eprocPID: the Safari one. Which makes sense since it's the audit_token for the sourceApp. But, IMO, it's not the pid of the network flow.

There is obviously a non official API to retrieve the eprocPID value since Objective-C is the nice language that lets you retrieve that kind of info easily.

The issue is that this is quite probably not considered as safe/secure as the way you get the eprocPID through the audit_token.

So:

[Q] How are we supposed to get the real pid from a NEFilterFlow?

Up vote post of packagesdev Down vote post of packagesdev
911 views
Posted by
packagesdev
Reply
Add a Comment

Replies

Please note I have already seen the answers pointing to the audit_token. How are we supposed to get the real pid from a NEFilterFlow?

Okay, if you are not wanting to use the standard API route to obtain the pid from the NEFilterFlow, then you could always extract this value from the NEFilterFlow description as well. Granted, you would have to develop a technique to parse this data, but it could be a route to investigate.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Add a Comment

I would just use the - (pid_t)pid private API if I had to get this value insecurely.

Posted by
packagesdev
Up vote reply of packagesdev Down vote reply of packagesdev
Add a Comment

I wanna be clear that the description property is intended for debugging and logging only. It is not safe to rely on the format of the resulting string. That’s not considered API. This is true not just for the NEFilterFlow type but for all types on our system. A while back we changed the format of the description property for NSData, and that broke a bunch of apps.

I’m still investigating the correct way to get the info discussed in this thread (s. 806055058), but I’m absolutely sure that parsing the description property is not that way.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

As Quinn mentioned using the description is not reliable. You'll be able to see what values that are coming through in the logs for debugging purposes, but for production use then you should use the sourceAppAuditToken.

Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Add a Comment

The story here is way weirder than I originally expected! I’ve made a note to post a summary hence once I’m done with the TSI.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment