Yes, do not activate a System Extension from a daemon, launch agent, command line tool, helper app, or any other mechanism other than the Container App for the extension. Doing so may cause issues and inconsistencies when deactivating and uninstalling. Can my launch agent be the Container App for the system extension? Or does it need to be separate?

Due to the audit subsystem being deprecated and now disabled in Sonoma, I am now moving towards using EndpointSecurity API to track invalid logins. I've been able to use the SampleEndpointApp to track ES_EVENT_TYPE_NOTIFY_AUTHENTICATION events. While waiting for approval for the EndpointSecurity entitlement, I've disabled SIP/AMFI on some test VMs. While doing some experimenting, I've noticed that the event message is not consistent across different macOS versions. For example, to capture user login attempts (valid or invalid), I was initially looking at the ES_EVENT_TYPE_NOTIFY_AUTHENTICATION message on macOS 14. Here, I can see that when looking inside: msg->event.authentication->data.od->instigator or msg->event.authentication->data.touchid->instigator I am able to discern if it is a matching event if the signing ID or executable is from the authorizationhost or coreauthd similar to what I looked for in the auditpipe. (I used a test device with macOS 14 and eslogger to verify the touchID part) However, on macOS 13, the data.od->instigator information is different. It is instead coming from loginwindow. I tried looking at the msg version/schema_version, but they match in both versions of macOS. So, my thought is, I can just ignore macOS 13 and only use the EndpointSecurity API if it is macOS 14 or newer (auditpipe still works on macOS 13 without having to re-enable the audit subsystem). But, my question now is, how likely is the instigator going to change in future versions of macOS? Am I going to need to re-examine this info for each subsequent release of macOS and add more conditions when checking for the desired events? I also looked into using the new ES_EVENT_TYPE_NOTIFY_AUTHORIZATION_JUDGEMENT in macOS 14, however, it does not produce an event when an invalid touch ID event occurs. (It also is not apparent how to distinguish between a valid touch id authentication vs a password authentication from the authorization_judgement event msg). So, I've decided to stick to ES_EVENT_TYPE_NOTIFY_AUTHENTICATION events for now.

Thank you for your insight.

Sorry, mistake in there: The LaunchAgent would then need to pass the TOTP secret back to the LaunchDaemon upon successful setup.

Some possible examples: The LaunchDaemon enforces security on a device. When setting up something like 2FA using an authenticator app, the user would interact with the LaunchAgent which handles the UI. The LaunchAgent would then need to pass the TOTP secret back to the LaunchAgent upon successful setup. In macOS 12, under System Preferences -> Security & Privacy -> FileVault, the "Enable Users..." button and functionality is no longer available. Our LaunchDaemon helps enforce/manage FileVault on the device. So we would like to add a UI component which simulated that functionality of adding additional users to be able to unlock FileVault so they won't need to do it via the command line. In this case, user credentials would be passed from the LaunchAgent to the LaunchDaemon.

One process is a LaunchDaemon and the other is a LaunchAgent.