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

Question

packagesdev OP

Created Nov ’21

Replies 5

Boosts 0

Views 1.1k

Participants 3

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?

Boost

Answer 1

Systems Engineer OP

Apple

Nov ’21

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

0

Answer 2

packagesdev OP

Nov ’21

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

0

Answer 3

DTS Engineer OP

Apple

Aug ’22

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"

1

Answer 4

Systems Engineer OP

Apple

Aug ’22

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.

0

Answer 5

DTS Engineer OP

Apple

Aug ’22

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"

0