Trying to flesh out an idea for an application which would rely on Endpoint Security Framework and Network Extension Framework, where intend the application to:
- Forward certain ESF events to a backend (on a separate server)
- Forward certain Unified logs to a backend (on a separate server)
- Forwarding various DNS queries and responses (on a separate server)
- Retrieve configuration from the backend to set Network Extension Filters
Are there any limitations and/or reasons not to bundle all this functionality into a single system extension?
I know of other applications where system extension is very thin and main application (daemon) communicates over xpc with the system extension, would this be considered best practice?
I know of other applications where system extension is very thin and main application (daemon) communicates over xpc with the system extension, would this be considered best practice?
I’m not sure what you mean my “main app” in this context but:
-
The app in which the sysex embedded is the container app.
-
The container app is an app, and by definition an app isn’t a daemon.
If you want to create a thin sysex and have it pass all of the work to your container app then, no, that’s not something I’d consider best practice. The container app, being an app, can only run when there’s an active GUI login session, but a sysex runs all the time.
If you want to run the container app executable as a daemon then that’s also not something I’d considered best practice. A daemon executable should not link to UI frameworks.
Creating and installing your own daemon and having a thin sysex that talks to that is fine. It may not be worthwhile — after all, a running sysex is effectively a daemon — but it’s not actively toxic.
Regarding your overall goals, my general concern is bandwidth and latency. An ES sysex is in a very privileged position in the system and, as such, it has to behave well. It’s very easy for a poorly written ES sysex to hose the system completely. In most cases the system will attempt to recover from that by killing the sysex, but that isn’t always effective.
My general advice is:
-
Minimise the events you claim.
-
Prefer notify events over auth events.
-
Respond to auth events promptly.
So:
Forward certain ESF events to a backend (on a separate server)
If this is an auth event then that’s not compatible with my last point in the list above. It may work for some very specific events but if, for example, you did this for every ES_EVENT_TYPE_AUTH_OPEN event, you would undermine system stability.
Forward certain Unified logs to a backend (on a separate server)
How are you getting those events? From OSLogStore? If so, that’d be fine, because that’s not on any hot path. You do still have to worry about bandwidth though.
Forwarding various DNS queries and responses (on a separate server)
That should be fine. DNS is a network operation and the system is generally tolerant of delays in those.
Retrieve configuration from the backend to set Network Extension Filters
That’s a standard pattern and I wouldn’t expect you to encounter problems implementing it.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"