Regarding Programs can’t authenticate themselves. I don't try to authenticate my own executable, I am trying to verify a helper binary/dylib inside my product that can be updated separately from the main binary. Before running/dlopening it, I would like to ensure: Test 1) The signature chain of the executable/dylib leads to the apple root. Test 2) The leaf certificate team-id is my team-id. Per my understanding this will ensure that this executable/binary was signed by me. If anyone else has a valid certificate(it can pass Test 1) but it will fail the Test 2 as its team ID will be different. If someone crafts a rogue certificate in order to pass Test 2 then this rogue certificate is not signed by apple and therefore will fail Test 1. Please advise if you see any problem with this approach. Now to my main question: When I try to extract the team id from the executable/dylib using SecCodeCopySigningInformation, I see some posts claim that if that executable is not signed by apple root chain team-id will come up as empty. I therefore ask: Approach 1: Is it enough to extract the team-id and compare to mine ? Does extracting a team-id(using SecCodeCopySigningInformation) automatically verifies that the anchor is apple ? OR Approach 2: Should I extract the team-id and compare it to mine AND in addition, manually verify the that anchor/root is apple ? I currently did "Approach 2" but it seems when I am trying to verify the anchor it sometimes takes several minutes for some reason and I see: trustd: [com.apple.securityd:SecError] Malformed anchor records, not an array Printed in the logs. I therefore wonder if its required at all.

Hi @DTS Engineer , perhaps you had a chance to check whether the secure enclave is reachable from a launchDaemon based application ?

Thanks for the comment @DTS Engineer . Unfortunately, when my app gets stuck on the main thread, it doesn't get crashed automatically and this meant bad user experience. The app is from type LaunchAgent and when I hover the app's icon in the upper menu bar, the cursor turns into a spinning wheel. that what led me to run the /usr/bin/sample command and see the callstack I've attached here. Perhaps you can tell me if there's any way to configure LaunchAgent to get crashed after x seconds from when the main thread got stack ? Also, I added 2 print messages before and after the setting of the Publish variable (self.event = eventType.evtSomething) and I could only see the 'before' message, so i'm confident that this is where it fails. I also try to omit this code line and got stuck on another similar setter. Perhaps you have any clue what might this phenomena be related to. unfortunately, this incident is pretty hard to reproduce. thanks !

Hi Quinn @DTS Engineer, thanks for clarifying. I do have a dedicated VPN server. My TransparentProxyProvider base its routing on flow details (for example NEAppProxyTCPFlow), deciding whether to send traffic directly or encapsulate it via the Packet Tunnel provider. I handle this by creating the socket to the remote endpoint and binding it either to the tunnel IP or the physical interface IP. Now, if I want to move to Network Extension (NE) provider instead of directly generate the vitual interface (utun), how can I acquire this information (the virtual adapter ip address).

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 !

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

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 !

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 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>

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 ?

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 ?

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 ?

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...

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)

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.