NSEndpointSecurityEarlyBoot shortcoming when no FDA / TCC rights are given to the extension

Originator:burcea.bogdan.madalin
Number:rdar://FB8978333 Date Originated:22-Jan-2021
Status:Open Resolved:No
Product:SystemExtensions Framework Product Version:macOS 10.15.4 and up
Classification:Suggestion Reproducible:Yes
 
There appears to be an unideal situation regarding EndpointSecurity System Extensions when using the NSEndpointSecurityEarlyBoot flag. The documentation (man EndpointSecurity) mentions about this flag that:

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.

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(). 

I am 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. 

My suggestion is to provide an alternative for es_subscribe() to signal readiness to the system from an Endpoint Security System Extension.

Comments

I've also made an apple developer forum post about this here: https://developer.apple.com/forums/thread/671895

By burcea.bogdan.madalin at Jan. 22, 2021, 2:36 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!