Hi Quinn and thanks for the answer, it indeed seems like the right solution for me, except for the fact that any privileged user can directly access the keychain item (see attached) Perhaps there's a way to prevent this ? Do I need the file-based keychain in this case, and create a dedicated keychain for this item with unique password that only the process will posses ? Or perhaps I can achieve my goal my simply using a different item (not password) that limit content viewing from outside the keychain API ? Thanks

Just a follow up question since you mentioned the concept DRM. So I've read the technical document about Apple version of DRM called "Apple FairPlay" and It looks like it's not good for application verification. I wonder if there's any built-in signing certificate in the keychain that is non-exportable (and is kept in the secure-enclave) and I can use it with my app to proof that the device i'm running my program from, is an expected device. This way, I can at least verify that the app is not installed in unauthorized machine...

I'm using boost-beast with openssl as an underlying socket. is it possible that launchAgent get less bandwidth when other foreground processes compete on the same resources ?

Hi meaton, basically my virtual interface is implemented by socket (old fashion) and not Network extension (I plan to implement using extension it in the future) . Anyhow, I've got a way to set the mtu. However, before that I need to find the pmtu from agent to server. So my basic desire is to trigger the pmtu discovery properly and than read it, and set it to my virtual interface... Currently I've tried to stimulate this flow using /usr/bin/nscurl but the pmtu remained the same (1500) Maybe I used small https messages... Perhaps you can advise me on a proper way to trigger the pmtu ? Maybe you can give me sample code for that or a terminal command ? Thanks !

Hi Quinn, SimplePing is written in objective-C so I couldn't use Int/CInt instead I replaced int val to uint32_t val just to make sure I work with 32, and also made sure that the function setsockopt returns 0 which symbolize success. However, when I trace the ping icmp packets in WireShark, I could clearly see that the DF bit is unset in the IP header. In the SimplePing example, they first create underlying BSD socket, and than use it to create the core foundation. Here the relevant code : fd = -1; err = 0; switch (self.hostAddressFamily) { case AF_INET: { fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP); uint32_t val = 1; if (fd < 0) { err = errno; break; } int x = setsockopt(fd, IPPROTO_IP, IP_DONTFRAG, &val, sizeof(val)); if (x < 0) { err = errno; } } break; // after creating the BSD socket it create the CFSocket self.socket = (CFSocketRef) CFAutorelease( CFSocketCreateWithNative(NULL, fd, kCFSocketReadCallBack, SocketReadCallback, &context) ); assert(self.socket != NULL); // The socket will now take care of cleaning up our file descriptor. assert( CFSocketGetSocketFlags(self.socket) & kCFSocketCloseOnInvalidate ); fd = -1; rls = CFSocketCreateRunLoopSource(NULL, self.socket, 0); assert(rls != NULL); CFRunLoopAddSource(CFRunLoopGetCurrent(), rls, kCFRunLoopDefaultMode); CFRelease(rls); I wonder if the DF option is being deleted somewhere when i create CFSocket from BSD socket.

Hey Quinn, The trick with using raw socket worked indeed. Thanks ! I just had to create the socket in the following manner fd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) and than I could use the setsockopt with the don't fragment flag. one thing still puzzles me ... I've asked in the past whether there's a way to use the pmtu that is calculated in the OS level. I got a reply that it's already being calculated when using high level frameworks like the NSURLSession.. However, from looking at wireshark it seems that the pmtu is calculated all over again for every new tcp connection... attached the wireshark traffic I saw for each https message I sent with NSURLSession based connection (you can see that it always starts with packet size as the mtu of current node, and after it gets rejections, it moved to the expected mtu which is 1000 - I deliberetly set the mtu of one of the hops on the way to this value) So I wonder if in macOS there's a pmtu cache at all per route ? I used to think it's in the routing table that can be aquired using the following API : mib[0] = CTL_NET; mib[1] = PF_ROUTE; mib[2] = 0; mib[3] = 0; mib[4] = NET_RT_DUMP; mib[5] = 0; sysctl(mib.data(), kSysctlMibLength, nullptr, &size_needed, nullptr, 0)

Thanks for your quick reply Quinn. I see that in your post you specifically refer to one of the use cases i'm trying to implement which is to catch file copying (either from finder or from terminal using cp) to remote fileStorage device. Perhaps you can give me some guidelines for how to approach this issue ? Does ES have high level interface for file copying ? Perhaps I should use DriverKit to catch the data being copied can block it until scan...

After running some diagnostics using fs_usage, I've found out that my application apply to the following file which is restricted : /Users/user/Library/Application Support/Knowledge/knowledgeC.db-wal I've read about this database, but i'm not sure which of the frameworks I attempt to access this file. Any idea which one should it be ?

It appears that I was wrong and the restricted file lies in /Users/user/Library/Autosave Information/ according to fs_usage, /Users/user/Library/Autosave Information/com.myComp.myApp.plist this file is probably copy of our app preferences file which have the same name /Users/user /Library/Preferences/com.myComp.myApp.plist but it looks like nothing is being written to that file, It just attempt to read this non-existent replica in Autosave folder and that what trigger the permission popup. I've tried to disable access to Autosave using the following command but it didn't work... defaults write com.myComp.myApp ApplePersistence -bool no i remove all known contents from my application and it still attempt to access this file in the folder. Any idea how i can avoid reading this file ?

Hi Quinn, one more insight I've got, when running the app using open, no attempt was made to access the Autosave Information folder. but when the app was run as lunchAgent using proper plist file under /Library/LaunchAgents/ than the attempt was made... does it make any sense ?

Hi Quinn thanks for your help. Here's the agent plist contents. Notice that if I run it directly and not as launchAgent, there's no attempt to access /Users/user/Library/Autosave Information/. does the plist contents may explain it ? <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.comp.prod.myAgent</string> <key>LimitLoadToSessionType</key> <string>Aqua</string> <key>Program</key> <string>/Applications/myApp.app/Contents/MacOS/myApp</string> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> </dict> </plist>

It worked on macOS 14 but no longer works on macOS 15. I suspect that new restrictions might have been introduced, preventing the DF (Don't Fragment) bit from appearing in ICMP requests. I attempted to generate such a packet using setsockopt by setting the DONTFRAG attribute on an ICMP connection, but it did not succeed. I also tried the same approach with UDP, but without success. Could this require new entitlements for setting the DF flag in a packet? Below are the entitlements of /sbin/ping. I recognize the last two, which are typically used when an app is sandboxed. However, could there be additional entitlements missing ? <key>com.apple.private.network.management.data.development</key><true/> <key>com.apple.private.virtualswitch.underlay-scoped</key><true/> <key>com.apple.security.network.client</key><true/> <key>com.apple.security.network.server</key><true/></dict> Thanks

Hi Kevin (@DTS Engineer) and thanks for your thorough reply. Per your query so our service (from type launchDaemon) do listen for system sleep events using the NSWorkspaceWillSleepNotification and NSWorkspaceDidWakeNotification via NSWorkspace.sharedWorkspace.notificationCenter. When getting the sleep event, we close all unnecessary components and only use minimal keepalive communication via websocket to a remote server. When getting the wake event, we reactivate the extra components implement the logic of our network product. In addition, we are using network extension that runs on a separated process, and runs several providers that intercept tcp/udp connections, filter packets, data and more. this extension isn't informed of the sleep wake events and continue as usual assuming that when the computer move to deep sleep, the process will be halted. Another point worth mentioning, our service was once running as a launchAgent, and now converted to run as launchDaemon, can it have an effect of the power consumption ? Perhaps with this information you'd be able to provide more insights ? Thanks !

Hi, Following @DTS Engineer advice, we’ve updated our implementation to stop using AppKit for handling system sleep and wake events, since our service now runs as a launchd daemon (not a LaunchAgent), as outlined in TN2083. We've replaced the NSWorkspaceWillSleepNotification / NSWorkspaceDidWakeNotification logic with the correct IOKit-based approach using IORegisterForSystemPower. Our daemon now listens for the following messages via a power management callback: kIOMessageCanSystemSleep – we acknowledge this using IOAllowPowerChange() kIOMessageSystemWillSleep – we enter suspend mode and allow the system to sleep kIOMessageSystemWillNotSleep – we log this for visibility kIOMessageSystemWillPowerOn and kIOMessageSystemHasPoweredOn – we resume internal state on wake However, it looks like, despite moving to daemon domain framework, the problem persists and the system is still prevented from from remaining in deep sleep for the entire sleep duration and it resulted in battery excessive drain. As mentioned, our product, which manages system and network extensions, was modified from an agent-based process running in the user domain to a daemon-based process running in the root domain. Below is the relevant configuration from its launchDaemon plist. Do you see anything here that could potentially cause the deep sleep prevention issue ? <key>KeepAlive</key> <true/> <key>RunAtLoad</key> <true/> <key>EnablePressuredExit</key> <false/> <key>POSIXSpawnType</key> <string>Adaptive</string> <key>ProcessType</key> <string>Interactive</string> Thanks

Thanks for your response Quinn @DTS Engineer . You’re correct, my VPN isn’t based on a Network Extension provider, but I do use a Transparent Proxy to divert some traffic outside the tunnel. Based on your suggestion, I’m considering building entirely on the NetworkExtension framework with two providers: NETransparentProxyProvider – intercepts app sockets so I can decide what to bypass. NEPacketTunnelProvider – encapsulates and encrypts the rest according to my VPN protocol. My goal is that each TCP/UDP socket first reaches the Transparent Proxy callback, and if diverted to the tunnel, then it flows the data through the Packet Tunnel provider for encapsulation before hitting the physical adapter. Is this the expected pipeline when both providers are active ? Thanks !