[NetworkExtension] [EndpointSecurity] [AppStore] [macOS] Can an app that uses a MitM-style network traffic interception be submitted to the AppStore?

Question

Created 1d

Replies 2

Boosts 0

Participants 3

Hello,

What are the restrictions on submitting apps to the mac App Store that use an NETransparentProxy alongside a locally installed and trusted Root-CA to intercept, decrypt and manipulate TLS traffic?

To be more specific, I'm not talking about a Safari extension. I'm talking about system-wide traffic. So that the app can detect and block ads and trackers from all apps, not just Safari. I'm aware that such an app can be distributed using an unsandboxed Developer-ID signed app. But I wonder if such an app also breaks Sandbox requirements for AppStore distributed apps?

Also, is there a way for a sandboxed app to install and trust a root CA? SecTrustSettingsSetTrustSettings does not work in Sandboxed apps from what I found.

Finally, I want to ask about EndpointSecurity. Can this entitlement be used in AppStore-ditributed apps?

Is doing any of these things possible on AppStore-distributed apps?

Thanks in advance for your reply.

Answer 1

DTS Engineer OP

Apple

1d

What are the restrictions on submitting apps to the Mac App Store?

If you want a formal answer, you'll need to raise the issue with App Review through one of their contact routes. However, informally...

that use an NETransparentProxy alongside a locally installed and trusted Root-CA to intercept, decrypt, and manipulate TLS traffic?

...

Finally, I want to ask about EndpointSecurity. Can this entitlement be used in AppStore-distributed apps?

...I wouldn't expect either of these to be allowed on the store. Apps that require privilege escalation generally aren't allowed on the store, and I believe both of these would. I'd also note that the ES API also requires Full Disk Access (FDA) and is probably the single most dangerous API on the system in terms of its ability to actively disrupt the user. With one small exception[1], I have a hard time imagining us approving any ES client onto the app store.

[1] We just introduced a new es_new_descendants_client() API which basically allows a parent process to restrict the activities of its child processes. I don't think it would be allowed in its current state (which requires a managed entitlement), but I could see it being allowed in the future, since the risks are fairly minimal[2] and the API quite useful in a variety of contexts. This forum thread has more detail if you're curious.

[2] The parent process can only see the actions of its direct children, so everything it's monitoring and blocking are things that it COULD have just done "itself", given enough time/energy/work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 2

DTS Engineer OP

Apple

1d

What Kevin said plus…

is there a way for a sandboxed app to install and trust a root CA?

No. In fact, this isn’t possible for a non-sandboxed app either. A few years back we changed our policy on this front. On modern versions of macOS there’s no way to install a trusted anchor without explicit user consent [1].

And I’ve no idea what App Review would make of you trying to do that in an App Store app.

I wouldn't expect either of these to be allowed on the store.

Kevin’s intuition is correct for ES. For NE the story is more nuanced. NE providers must be sandboxed, so my understanding is that we allow both the appex and sysex variants on the App Store. And, yeah, that means you end up with sysex-packaged NE providers running as root but in a sandbox. It’s a bit weird.

Having said that, both Kevin and I work for DTS and we can’t provide definitive answers about App Review policy. So I’m gonna repeat Kevin’s advice: If this stuff is critical to you, talk to App Review directly.

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

[1] The exception is MDM, but you can think of that as the user consenting when they signed up for management.