Hello, As I understand it, the ES framework provides notifications for specific event types. For my question, auth events do not matter, as I'm not interested in allowing/denying events, just reporting. Is there a way to retrieve the information if an event was successful/failed from an ES message? So far, I have found nothing in this regard in the documentation. For example, under certain circumstances, I get two notifications if I try to delete a file via the Finder, for which administrator privileges are required. The first is when the authorization dialog appears (this notification is for the failed unlink event), and the second is when I enter the correct credentials and the file is deleted. Example for reproduction: Open a terminal and create a file in "/etc" with the command "sudo touch test.txt". Run the command 'sudo eslogger unlink | grep -E "test.txt"' to start monitoring UNLINK events for files named "test.txt". Open the folder "/etc" in Finder. Select the file "test.txt", click on "File" in the menu, and hold the option key pressed. Then select "Delete Immediately...". In the appearing dialog, click on "Delete". Before entering the administrator password, and while the credentials dialog is still open, observe that eslogger already reports an UNLINK event for this file. It reports the user information: "ruid":501,"euid":501,"rgid":20,"auid":501,"egid":20. Enter the administrator password to confirm the deletion of the file. Observe that eslogger reports a second UNLINK event for this file. This time with the user information: "ruid":0,"euid":0,"rgid":0,"auid":501,"egid":0. So, is there a way to check the first event for failure? Otherwise, I would need to check manually if the file is still there after receiving the first notification, if I only want to report events that "really" happened (excluding attempts).

I'm working on a System Extension that uses the EndpointSecurity framework to monitor various events. For some events, we're using ES_EVENT_TYPE_AUTH_* events, and actively preventing certain changes. All this works fine, while the extension is running. This is not an anti-virus product, but is similar enough that it might help to think of it that way for purposes of this discussion. Much like any anti-malware tool, we'd like for the System Extension to be resilient to malicious processes, even processes running as root. If any random process that gets root can do the equivalent of kill -9 <my extension>, or systemextensionsctl uninstall <my extension>, then it's easy enough for them to kill the extension, then do something we would otherwise prevent. It's also possible for an end user to drag-uninstall the app, which disables the extension immediately, before we even have a chance to respond to any changes. I know that various anti-virus software for Macs address this, and prevent a user from, for example, using sudo kill -9 <pid> to disable them. How is that typically done? Some possible approaches could be: Have two processes that watch each other, and restart each other if killed. There's a timing issue there that I'm not sure is easy to resolve, and I haven't tried launching a detached process from a system extension - that might not even work. I could have a separate launchdaemon which periodically checks to see if the extension (and app) are installed, and reinstalls them if they're missing. That leaves plenty of time for mischief to occur, but at least I'd have a window to detect it. It sounds like the NSEndpointSecurityRebootRequired Info.plist key might have some effect here, in that it prevents an extension from being replaced until a reboot. I should check and see what effect if any this has on removing the app or killing the extension. Maybe there's a System Profile setting that could be set through an MDM to prevent the application from getting uninstalled? I don't know my way around profiles very well, and I doubt this would address the "kill" issue, in any case. Probably there's some lower-level BSD or Mach API that could prevent attempts to kill the process. I could make a kernel extension for just this one thing, maybe using kauth(), but that seems overkill, and kernel extensions are not the Apple-suggested way to do anything these days. If EndpointSecurity is intended to replace using kexts for anti-malware and detection uses, there must be a way to do this inside a system extension, right? So, yeah - preventing the user from doing something is going against the spirit of "do what you like with your own computer, especially if you have admin powers", but this software is typically going to be installed by corporate IT, not end users, and some end users "need" admin permissions (e.g. software developers)... Any suggestions would be appreciated.

My team requested com.apple.developer.endpoint-security.client entitlement 4 months ago and receive no response from Apple. What will we do to claim our entitlement in Developer ID Certificate.

I have an app that uses Apple's Endpoint Security system extension to collect a number of events including authentication events. I've noticed AKD (Apple Keychain Daemon?) generates fail authentication events when I unlock my Mac with either Touch ID or password. I don't think I've ever seen it succeed. Does anyone know what AKD is trying to authenticate and why it is failing? Should I mask these out from being shown, or are there cases where AKD authentication will matter? Hardware: MacBook Pro with M1 OS: macOS 13.5.2 Device is configured stand-alone (not a managed device)

I started a daemon app with esf function through launchctl. I wanted to get the sample information of the daemon app through sample, but the program would restart, which was not a crash. // shell command sample pid -file ~/Downloads/test.txt

Apple's Endpoint security framework seems to have ways to prevent deleting of file. If we write an app that has a system extension that uses this framework, will the same app be able to prevent deletion if its own .app file ? If yes, when a user attempts to delete the app from /Applications folder, can we ask the user to enter a 'master password' before user is able to delete the app ? The app is sandbox, signed by develope id, and for MacOS.

I implemented a multithreaded app, but there was a thread-related crash in the app, I don't understand why this happened, the corresponding stack trace is as follows. Thread 15 Crashed:: Dispatch queue: com.apple.root.default-qos 0 libsystem_kernel.dylib 0x1a849ad98 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1a84cfee0 pthread_kill + 288 2 libsystem_c.dylib 0x1a840a340 abort + 168 3 libc++abi.dylib 0x1a848ab08 abort_message + 132 4 libc++abi.dylib 0x1a847a950 demangling_terminate_handler() + 336 5 libobjc.A.dylib 0x1a8370320 _objc_terminate() + 144 6 libc++abi.dylib 0x1a8489ea4 std::__terminate(void (*)()) + 20 7 libc++abi.dylib 0x1a8489e40 std::terminate() + 64 8 libdispatch.dylib 0x1a830c1c8 _dispatch_client_callout + 40 9 libdispatch.dylib 0x1a831da04 _dispatch_root_queue_drain + 680 10 libdispatch.dylib 0x1a831e104 _dispatch_worker_thread2 + 164 11 libsystem_pthread.dylib 0x1a84cc324 _pthread_wqthread + 228 12 libsystem_pthread.dylib 0x1a84cb080 start_wqthread + 8

Recently we've discovered an issue affecting our products in regards to using the Monterey+ provided new api calls to selectively mute events. Specifically, whenever using es_mute_process_events or es_mute_path_events, the ES_EVENT_TYPE_NOTIFY_OPEN event is ignored for muting (meaning the call will return success, but the event will keep coming). This is true only for this event as far as I can tell, its AUTH counterpart stays muted (along lots of other processes: clone, rename, close, unlink, fork etc). It fails if either the event is in a list of events or if the event is singled out in 1 sized vector of events. When using a dedicated client for this event and using the previous api, es_mute_process or es_mute_path muting works as intended. Tested on ventura 13.5 and 13.6. Is there something that can be done to prevent dedicated clients or is this a known issue?

I am playing around with Endpoint Security using demo code. I tried to handle AUTH open event on specific folder in my Desktop,set to deny all, but whenever I set this extension, I successfully get deny all on the folder as well as all other files and documents in the Users space. static void handle_open_worker(es_client_t *client, const es_message_t *msg) { static const char *test_nnn = "/Users/myname/Desktop/endpoint_test/block_this_folder/"; static const size_t nnn_length = sizeof(test_nnn) - 1; if (strncmp(msg->event.open.file->path.data, test_nnn, nnn_length) == 0) { es_respond_flags_result(client, msg, 0, true); } else { // Allow everything else... es_respond_flags_result(client, msg, 0xffffffff, true); } } why the code applies to all other files rather than only deny open on /Users/myname/Desktop/endpoint_test/block_this_folder/

Hi all, I'm developing an app that can disallow read and/or write access to selected files. I'm doing this with es_respond_flags_result: es_respond_result_t es_result; if (blockingState) { // Don't allow any operations on path... es_result = es_respond_flags_result(client, msg, 0, false); // Deny writing to path... // es_respond_flags_result(client, msg, 0xffffffff & ~FWRITE, true); // Deny reading of path... // es_respond_flags_result(client, msg, 0xffffffff & ~FREAD, true); } else { // Allow everything else... es_result = es_respond_flags_result(client, msg, 0xffffffff, false); } While everything works correctly for files on the desktop, blocking fails for files in the "/System/Library/" path. Everything worked great under macOS Ventura. Now on macOS Sonoma it does not work anymore. On macOS Sonoma I still get ES_RESPOND_RESULT_SUCCESS as the result from es_respond_flags_result but the files can still be read/written. What has changed in macOS Sonoma? I cannot find anything about this in the change logs. Are more adjustments needed for macOS Sonoma? Thanks for any advice! nm196

I have an app that installs an endpoint system extension, and I have the app notarized. I can install the endpoint system extension and enable Full Disk Access fine on Ventura, Apple Silicon Sonoma, Apple Silicon But I cannot enable Full Disk Access on Ventura, Intel In System Settings, when I try to slide toggle switch on to enable full disk access, the toggle slides right back to off. In previous development versions, I could enable Full Disk Access on the Intel machine. Any idea why I cannot enable Full Disk Access on Ventura/Intel for my endpoint system extension in my notarized app? One additional observation, the name displayed in the Full Disk Access section is different between the Apple Silicon and Intel Macs. On Apple Silicon, only the final part of the Bundle ID is shown in Full Disk Access: endpointagent On Intel, the full Bundle ID is shown: com.MyCompany.MyApp.endpointagent Don't know if it matters, but I thought I'd point that out.

I am currently writing an agent for endpoint security. I cannot connect the application and the xpc service. I start the plist with launchctl and then open the application, but it does not connect and the application runs dysfunctionally. I leave the code of the ViewController in the application and the XPCConnection in the xpc service below. Note: I create the XPC service in Xcode like a normal application and write it as a service application with "Application is background only" ViewController.swift func establishConnection() { XPCConnection.shared.connectToDaemon(bundle: Bundle.main, delegate: self) { success in DispatchQueue.main.async { [self] in if !success { controlButton.isEnabled = false configMenuStatus(start: false, stop: false) alertWithError(error: "Unable to start monitoring for broken connection with daemon.") } else { Logger(.Info, "Connect to daemon successfully.") } } } } XPCConnection.swift func connectToDaemon(bundle: Bundle, delegate: ClientXPCProtocol, handler: @escaping (Bool) -> Void) { guard connection == nil else { Logger(.Info, "Client already connected.") handler(true) return } guard getMachServiceName(from: bundle) == ClientBundle else { handler(false) return } let newConnection = NSXPCConnection(machServiceName: DaemonBundle) newConnection.exportedObject = delegate newConnection.exportedInterface = NSXPCInterface(with: ClientXPCProtocol.self) newConnection.remoteObjectInterface = NSXPCInterface(with: DaemonXPCProtocol.self) newConnection.invalidationHandler = { self.connection = nil Logger(.Info, "Daemon disconnected.") handler(false) } newConnection.interruptionHandler = { self.connection = nil Logger(.Error, "Daemon interrupted.") handler(false) } connection = newConnection newConnection.resume() let proxy = newConnection.remoteObjectProxyWithErrorHandler { error in Logger(.Error, "Failed to connect with error [\(error)]") self.connection?.invalidate() self.connection = nil handler(false) } as? DaemonXPCProtocol proxy!.connectResponse(handler) handler(true) } This is the error photo, the application continues to work First, I checked to see if I had made a mistake in the bundle identifier, but I could not find an error, and then I realized that I had not run the launchd service. Then I ran it, but it did not make any sense. What I am trying to do is to connect and run the network extension and endpoint security with this service, but the xpc service does not connect to each other.

Hello community we have been using an Endpoint Security client within a system extension for quite a while now. After some users updated macOS to Sonoma, we got complaints about slower performance when using MS Office on Mac. The product features work as expected, and our system extension is loaded and delivers events. Upon inspection of the log files, we found the following (but not on all machines): [com.apple.TCC:access] Failed to create LSApplicationRecord for file:///Library/SystemExtensions/0062566E-9869-4CC4-A666-F641F5C011CD/com.sophos.endpoint.scanextension.systemextension/: 'The operation couldn’t be completed. (OSStatus error -10811.)' and [com.apple.TCC:access] -[TCCDAccessIdentity staticCode]: static code for: identifier com.sophos.endpoint.scanextension, type: 0: 0x7fb63da318c0 at /Library/SystemExtensions/0062566E-9869-4CC4-A666-F641F5C011CD/com.sophos.endpoint.scanextension.systemextension for almost each event delivered. We are using XPC from the system extension to a non-priviliged daemon process to process file content. A feedback has already been filed: FB13174804 An additional code-level support was returnd woithout any explanation. Signing checks of the system extension and the containing app (daemon) on Sonoma turn up without any errros. Any idea, whats going on here? Frank Fenn Sophos Inc.