Posts

Post not yet marked as solved
5 Replies
1.4k Views
Hello, I've been working with system extensions on macOS Catalina / Big Sur (Endpoint Security extensions to be precise) and it seems that there is no 'right' way to check whether a system extension has already been approved by the user or not. You can of course use an activation OSSystemExtensionRequest and determine through the OSSystemExtensionRequestDelegate whether the user needs to approve it (a 'requestNeedsUserApproval:' message is passed) or if the extension has been loaded into the system (a 'request:didFinishWithResult:' message is passed). That's great but the major drawback is that making such a request when the extension is not loaded also starts the process of loading the system extension: The user is shown a system popup window and the 'Allow' request shows up in System Preferences > Security & Privacy. I'm looking for a non-intrusive way of checking the load status of the system extension. I think being able to do this is very useful. Say, for instance, you have an app with optional features, one of which requires the activation of a system extension. If we could check the load status of that system extension, we could display to the user a proper UI that can either suggest that it could be activated or show to the user that it is already approved and working. There are some ways to achieve this that I've thought about, but they don't seem the proper way of doing things: 1) Trying to parse the output of 'systemextensionsctl list'. It seems problematic since an extension can appear multiple times in here (based on succesive activations / deactivations) and also since the output isn't particularly documented. 2) Opening an NSXPCListener from inside the system extension and determining the activation status of the extension by whether or not a process can connect to this. 3) Attempting to look for a TeamId.com.mybundle.identifier process in the output of a 'launchctl' command, such as 'sudo launchctl list TeamId.com.mybundle.identifier 2>&1 | grep PID'. I've been using this method and it seems consistent for now. Is there a recommended way of achieving this?
Posted
by bburcea.
Last updated
.
Post not yet marked as solved
2 Replies
753 Views
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: 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 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?
Posted
by bburcea.
Last updated
.
Post marked as solved
3 Replies
2.3k Views
Hello,I've been fiddling with safari app extensions and I've found the following issue: While the messages sent from the content scripts are always sent to the background code (Swift in my case) when calling safari.extension.dispatchMessage(), the same cannot be said about the messages sent from the background code to the content scripts: There are some situations where the code reaches the call to the page.dispatchMessageToScript(withName: , userInfo: ), but the message doesn't reach the content scripts (i.e.: the event handler doesn't get called).From what I've seen, this can happen when doing some back-and-forth navigating between two webpages. I've managed to reproduce this situation with the code bellow.I've just created the template structure for the Safari App Extension in Xcode. I've then modified the scripts.js file todocument.addEventListener("DOMContentLoaded", function() { document.addEventListener("keydown", function(event) { switch (event.key) { case "ArrowLeft": window.location.href = "https://www.google.com"; break; case "ArrowRight": window.location.href = "https://www.bing.com"; break; case "ArrowDown": safari.extension.dispatchMessage('down'); break; } }); safari.self.addEventListener("message", function(event) { if (event.name === 'down') { console.log("Background code says that the down arrow was pressed"); } }); });and the messageReceived method in SafariExtensionHandler to the following: override func messageReceived(withName messageName: String, from page: SFSafariPage, userInfo: [String : Any]?) { if (messageName == "down") { page.dispatchMessageToScript(withName: "down", userInfo: nil) } }Note: I have set the SFSafariWebsiteAccess to All.The script simply redirects to "www.google.com" when pressing the left arrow key and to "www.bing.com" when pressing the right arrow key. Also, when pressing the down arrow key, a message is sent to the Swift code only to be received back in the event handler and log a message to the browser console. When entering a new webpage in a tab, the down arrow logging works fine. However, if you do a bit of navigating between google and bing by using the arrow keys, the down arrow logging will stop working. And this is because page.dispatchMessageToScript doesn't actually send the message, but the execution still reaches that call. I can't specify exactly how much navigating needs to be done to reproduce the problem as this seems to be somewhat inconsistent.My operating system is macOS Mojave with Version 10.14.5 (18F203)My Xcode version is 10.2.1 (10E1001)My Safari version is 12.1.1 (14607.2.6.1.1)Note that I'm pretty sure this bug happened with some previous versions of these software aswell.
Posted
by bburcea.
Last updated
.