I've encountered what appears to be an unideal situation regarding EndpointSecurity System Extensions when using the NSEndpointSecurityEarlyBoot flag. The documentation (man EndpointSecurity) mentions about this flag that:
I was hoping to avoid this hangup when possible, as it doesn't appear to provide the best user experience, by having the system extension tell the OS to proceed whenever it detects a situation that probably won't fix itself immediately (such as the extension having no TCC rights given), but this doesn't always seem possible.
Am I missing something?
This does work exactly as described. However, it seems that there are situations in which an ES system extension simply can't get to the point of making an es_subscribe() call, by far the most common one being when the user has yet to give Full Disk Access / Transparency, Consent, and Control rights to the extension. In a situation like that, the extension can't get past the es_new_client() call, as it will fail repeatedly with the ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED return code and without a valid es_client_t * value, es_subscribe() can't be called. So the system is stuck at boot time waiting what seems to be close to a minute for an extension that can't make an es_subcribe().NSEndpointSecurityEarlyBoot
Type: Boolean
If set to TRUE, the ES subsystem will hold up all third party executions (anything that is not a platform binary) until all early boot ES extensions make their first subscription.
I was hoping to avoid this hangup when possible, as it doesn't appear to provide the best user experience, by having the system extension tell the OS to proceed whenever it detects a situation that probably won't fix itself immediately (such as the extension having no TCC rights given), but this doesn't always seem possible.
Am I missing something?
