能够在扩展过程中使 macOS 端点扩展失败

Question

I'd like to protect against unauthorised system extension teardown that are triggered by the container application following this command:

self.deactivationRequest = 
        OSSystemExtensionRequest.deactivationRequest(
                    forExtensionWithIdentifier: extensionIdentifier, queue: .main)
self.deactivationRequest!.delegate = self
OSSystemExtensionManager.shared.submitRequest(self.deactivationRequest!)

Is there a callback in the endpoint extension code, that can be invoked upon this deactivation request, and may block/allow it?

thanks

Answer 1

There is no public API to control the system extension deactivation with EndpointSecurity or inside sysext itself (activation and deactivation management, I think, is a job for some daemon, like sysextd).

I could advice to try two approaches for your case:

1. You may still be able to deny deactivation with EndpointSecurity, just not in direct way. To deactivate sysext the responsible processes would do a lot of stuff, including opening some specific files, reading them, etc. In case you are lucky, you may be able to fail the deactivation process by blocking one of such operations before it really deativated. However, the context of operation (how do you know the target is your extension) may vary and be less than you need.

2. You may intercept the OSSystemExtensionManager.shared.submitRequest call inside your application, and add some condition to really call original method from interception method. The interception for submitRequest will be a swizzling . Or you can place an old good hook on something deeper, like xpc_* stuff, and filter your deactivation request by some unique string from request, also calling original method only on some condition.

Both ways are not bulletproof from perspective of tampering protection ofc, but nothing really is, we just requesting additional efforts from hacker.

If you haven't disabled library validation for your app, there are two ways of tampering it: either turning SIP off, or using some 0-day system breach. You can't really protect your app from such treats: 0-days are new, you don't know what it may be, and with SIP off the one may unload/disable/alter all possible kinds of protection stuff.