Hello,
I am working on a network security and DLP (Data Loss Prevention) solution. A core requirement of our architecture is the ability to modify network traffic payloads in-flight (e.g., stripping sensitive data or altering packets). So, the only way to implement this is via the NETransparentProxyProvider which allows us to handle, evaluate, and modify network flows (NEAppProxyFlow).
However, because this is such a powerful mechanism, my primary goal is to ensure the absolute stability of the operating system. I want to minimize the risk of interfering with core Apple services. When evaluating a flow, I have access to NEFlowMetaData, specifically properties like sourceAppUniqueIdentifier and sourceAppAuditToken.
Could you please assist me with the following questions:
- Is there a recommended list of Apple system Application IDs (Bundle IDs) or executable names that should be strictly bypassed (ignored) by the Network Extension to maintain system integrity?
- Since system daemons can change between OS releases, are there any programmatic best practices or specific rules to dynamically identify core OS traffic that must not be intercepted?
- Are there any specific network ports or protocols that Apple strongly recommends excluding from NENetworkRule matches at the proxy provider configuration level to ensure daemons like apsd or mDNSResponder function correctly?
Thank you in advance.
So there aren’t hard’n’fast rules here. I can explain some tools that you have available, but you have to make your own judgement calls as to best to use those tools in your product.
The most critical item here is the sourceAppAuditToken property. This holds the bytes of an audit_token_t, and from that you can use the code signing machinery to get information about the process and its main executable. I’ve talked about this a bunch of times here on the forums. This post has a snippet you can copy, but it’s probably worth you searching for other similar threads for more advice.
IMPORTANT The first part of the snippet, getting the audit token and passing it to the code signing API, is canonical. The second part, getting the bundle ID, is not. Bundle IDs aren’t secure on macOS.
Once you’re in ‘code siging space’ you can use code signing requirements to check the code in question. For example, the anchor apple requirement will tell you whether the code is from Apple. TN3127 Inside Code Signing: Requirements talks about code signing requirements in depth.
1- Is there a recommended list of Apple system Application IDs (Bundle IDs) or executable names that should be strictly bypassed (ignored) by the Network Extension to maintain system integrity?
No.
For a start, bundle IDs and executable names aren’t a valid way to identify code but, even if you do identify the code correctly, via its designated requirement, see TN3125, there’s no documented list of processes that you must stay away from.
2- … are there any programmatic best practices or specific rules to dynamically identify core OS traffic that must not be intercepted?
No.
3- Are there any specific network ports or protocols that Apple strongly recommends excluding … ?
The best place to look for that sort of information is in the Apple Support documentation. They publish information like that for the benefit of folks deploying firewalls. My go-to reference is TCP and UDP ports used by Apple software products, but there’s probably more info in other resources, including Apple Platform Deployment.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"