I'm trying to build and run the Endpoint sample code from Apple's "Monitoring System Events with Endpoint Security", but the extension keeps crashing apparently because the code signature is invalid. Any help would be appreciated. Details: Because our endpoint entitlement isn't approved yet, I've disabled SIP. I am running on the latest macOS 13.0 beta (22A5295i). The extension is installed, and I grant it full disk access. systemextensionsctl shows it is installed, but launchctl shows its status is -9 Console shows a crash because Code Signature Invalid Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CODESIGNING 1 Taskgated Invalid Signature I've set the Team ID to my organization. The signing certificate is my Apple Development certificate. Any other recommendations?

I am having troubles communicating with my endpoint security system extension without setting com.apple.security.temporary-exception.mach-lookup.global-name The system is a MacBook Pro with M1 Pro running Ventura beta 22A5295i. The endpoint security is installed by a regular app, and it is running fine. Because we do not have the endpoint entitlement yet, SIP has been turned off and amfi_get_out_of_my_way set to 1. The endpoint security agent has NSEndpointSecurityMachServiceName set to the service name - (Team).bundle-ID.xpc All the apps are part of the same app group. I created a third app (with the same app group) to communicate with the endpoint agent over XPC, but it fails unless I do one of the following: Disable its sandbox Add com.apple.security.temporary-exception.mach-lookup.global-name Will this problem go away once we have the endpoint entitlement? Or am I doing something else wrong? Thanks

In my own code I am seeing team_id (in es_process_t) is set to zero length. eslogger is also displaying this field as null. Is this expected going forward, or is this a bug? Environment: macOS Ventura: 13.0 Beta (22A5331f) CPU: Apple M1 Pro SIP disabled amfi_get_out_of_my_way=0x1

Is there a Swift to C API that delivers the same functionality as the codesign command? I would like, given a path to an executable, determine if it has been signed, and if so, extract the TeamIdentifier and Identifier values.

I have a question about the amount of trust I should have in the team_id for an executable. I've been looking at the signing_id and team_id values in Apple's endpoint es_process_t, and almost all code follows the reverse naming scheme for their team_id. They have names like: com.getdropbox.dropbox com.microsoft.teams.helper com.apple.mdworker_shared com.apple.spctl But Google (at least) violates this reverse DNS pattern when signing many of their binaries. They have team IDs such as ksfetch GoogleSoftwareUpdateDaemon crashpad_handler Should I not trust the TLD (e.g., com.apple or com.microsoft) for the team ID? For example, could Google (or a malicious organization) sign their binary com.microsoft.ksfetch making me think it came from Microsoft?

Is there a way to determine if a system call like open() succeeded or failed using the data from the endpoint security system? I tried a test where I created two files owned by another user. One was world readable and one was not. Back in my account I started eslogger and watched for open calls to those two files. % sudo eslogger open | egrep 'Secrets' I then did the 'cat' command on each file. One call succeeded, and one call got a permission denied (as expected). I've been combing through the JSON output from eslogger for both open() calls, but I cannot find any difference in the two system call outputs indicating success or failure. (I'm guessing we get the NOTIFY event before a determination is made by the kernel whether to allow the system call or not) Example output from the failed system call: { "schema_version": 1, "mach_time": 1355207989229, "event_type": 10, "thread": { "thread_id": 744065 }, "version": 7, "seq_num": 32, "event": { "open": { "fflag": 1, "file": { "path": "/Users/netsqllc/Secrets/UFOs", "stat": { "st_blocks": 8, "st_blksize": 4096, "st_rdev": 0, "st_dev": 16777234, "st_uid": 503, "st_gid": 20, "st_ino": 64075033, "st_birthtimespec": "2023-04-14T23:31:43.252266533Z", "st_flags": 0, "st_nlink": 1, "st_mtimespec": "2023-04-14T23:31:43.252436825Z", "st_ctimespec": "2023-04-14T23:32:26.842642260Z", "st_size": 27, "st_gen": 0, "st_mode": 33152, "st_atimespec": "2023-04-14T23:32:15.095239992Z" }, "path_truncated": false } } }, "time": "2023-04-14T23:37:55.000772617Z", "action": { "result": { "result": { "flags": 4294967295 }, "result_type": 1 } }, "process": { "signing_id": "com.apple.cat", "parent_audit_token": { "asid": 100869, "pidversion": 25015, "ruid": 501, "euid": 501, "rgid": 20, "auid": 501, "egid": 20, "pid": 9666 }, "codesigning_flags": 570506001, "executable": { "path": "/bin/cat", "stat": { "st_blocks": 32, "st_blksize": 4096, "st_rdev": 0, "st_dev": 16777234, "st_uid": 0, "st_gid": 0, "st_ino": 1152921500312435790, "st_birthtimespec": "2023-04-01T16:46:50.000000000Z", "st_flags": 524320, "st_nlink": 1, "st_mtimespec": "2023-04-01T16:46:50.000000000Z", "st_ctimespec": "2023-04-01T16:46:50.000000000Z", "st_size": 135408, "st_gen": 0, "st_mode": 33261, "st_atimespec": "2023-04-01T16:46:50.000000000Z" }, "path_truncated": false }, "ppid": 9666, "tty": { "path": "/dev/ttys002", "stat": { "st_blocks": 0, "st_blksize": 65536, "st_rdev": 268435458, "st_dev": 1683689770, "st_uid": 501, "st_gid": 4, "st_ino": 795, "st_birthtimespec": "1970-01-01T00:00:00.000000000Z", "st_flags": 0, "st_nlink": 1, "st_mtimespec": "2023-04-14T23:37:54.994777000Z", "st_ctimespec": "2023-04-14T23:37:54.994777000Z", "st_size": 0, "st_gen": 0, "st_mode": 8592, "st_atimespec": "2023-04-14T23:37:53.994681000Z" }, "path_truncated": false }, "start_time": "2023-04-14T23:37:54.994975Z", "is_platform_binary": true, "group_id": 9717, "audit_token": { "asid": 100869, "pidversion": 25112, "ruid": 501, "euid": 501, "rgid": 20, "auid": 501, "egid": 20, "pid": 9717 }, "is_es_client": false, "responsible_audit_token": { "asid": 100869, "pidversion": 24236, "ruid": 501, "euid": 501, "rgid": 20, "auid": 501, "egid": 20, "pid": 9371 }, "session_id": 9665, "original_ppid": 9666, "cdhash": "946128EF09844AABFF0A1E16D6D0C435D35AB098", "team_id": null }, "action_type": 1, "global_seq_num": 32 }

Looking at the certificate chains for various binaries (using Apple's APIs or codesign --vvd) shows several patterns for the common names. I am wondering why some code has the structure Apple Root CA Developer ID Certification Authority Developer ID Application: Google LLC (EQHXZ8M8AV) while others have the pattern Apple Root CA Apple Worldwide Developer Relations Certification Authority Apple Mac OS Application Signing Note, the second pattern does not include an organizational name. Why is there a difference? Is the second pattern an older pattern and the first (with the organization name) the new pattern? (There are other certificate patterns like for Apple's binaries and development code I am testing)

IIRC, when Apple introduced the new Network Extension and Endpoint Security system extension architectures, apps with Network Extensions in their bundle had to be distributed through the Mac App Store, whereas apps with Endpoint Security extensions could not be distributed through the Mac App Store (or vice versa). I can no longer find language on such restrictions. Can I distribute an app with both a Network Extension and an Endpoint Security extension in the same app bundle via the Mac App Store?

I noticed jq (installed from Homebrew) has an ad hoc signature and is rejected by spctl but runs fine. I don't remember ever being prompted by my Mac as to whether this binary should be allowed to run. I repeated the experiment with another binary (aescrypt) downloaded from Homebrew. Should Gatekeeper prevent these binaries from executing until I intervene? Is there any online documentation explaining the conditions that allow some binaries that are rejected by spctl and have no signature chain rooted at Apple to execute? (Or am I just not understanding how to use Gatekeeper and spctl?) codesign analysis: % codesign -vvd /opt/homebrew/bin/aescrypt Executable=/opt/homebrew/Cellar/aescrypt/0.7/bin/aescrypt Identifier=aescrypt Format=Mach-O thin (arm64) CodeDirectory v=20400 size=545 flags=0x20002(adhoc,linker-signed) hashes=14+0 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements=none And checking spctl analysis: % spctl --assess -vvv /opt/homebrew/bin/aescrypt /opt/homebrew/bin/aescrypt: rejected

If I distribute an app through the Mac App Store that includes a Network Extension that must be installed (and getting the user's permission in the process), and later I submit an update to the app (although no changes to the network extension piece) through MAS, will the user need to re-install the Network Extension? That is, does updating an app with that has a Network Extension remove the previous Network Extension from the system?

I ran into a strange problem during development this morning. When trying to install my Endpoint and Network System Extensions (something I was able to do yesterday, and many times before), my Mac is prompting me to enable Kernel Extensions. Right before this happened, I had problems deleting the previous version of the apps from the /Applications folder (it took many tries). This too was unusual. After agreeing to allow the installation of my Endpoint System Extension, I was greeted with this previously unseen message and button: When I click "Enable System Extensions...", and I am greeted with this alert: I also ran into this problem when trying to install my Network System Extension. Anyone have any idea how I screwed up my system? Anyone know how to return it to normal behavior? System: Mac Studio 2022 OS: Ventura 13.4.1 (I'm thinking of re-instaling Ventura this evening; would prefer not to)

I have a regular GUI-based app that communicates with an Endpoint System Extension installed by another app. Both the GUI app and Endpoint System Extension have the same Team ID and are part of the same App Groups. But I still need to do one of the following to the GUI-based app to allow it to communicate with the Endpoint System Extension over XPC: Disable the sandbox Add com.apple.security.temporary-exception.mach-lookup.global-name to entitlements For some reason I thought there was another way to resolve this. Am I missing anything? (My goal is to allow an app distributed through the Mac App Store to communicate with my Endpoint System Extension if it exists, and I am worried about the "temporary-exception" entitlement needed to support this.)

I ran into a strange situation (bug?) today trying to resize the relative height of two views in a VStack on macOS. I accomplished this by inserting a thin rectangle between the two views and applying a DragGesture to it. It works fine... until it doesn't. It takes a lot of changing of the view heights before I hit the bug, but if I drag & release enough times, I will eventually hit it. At some point, the code goes into an infinite loop and the program effectively freezes. os_log() is showing the .onChange value.height continuously flip flopping between -0.25 and +0.25. I found a kludge/work-around. If the onChange's absolute value is less than 1, I don't update the frame hight. Then the code runs like a champ. Am I doing something wrong? Is this a bug I should file? Here is the SwiftUI test code: import SwiftUI import os.log struct ResizableViews: View { @State private var height: CGFloat = 200 let minHeight:CGFloat = 30 let maxHeight: CGFloat = 400 var body: some View { Group { VStack (spacing: 0) { Rectangle() .fill(Color.blue) .frame(height: height) // The draggable rectangle/handle Rectangle() .background(Color.gray) .frame(height: 10) .gesture( DragGesture() .onChanged { value in os_log("CHANGE \(value.translation.height)") // abs() > 1 is a kludge to avoid infinite loop // with value changes flipping between -0.25 and // 0.25 if abs(value.translation.height) >= 1 { let tmpHeight = height + value.translation.height height = min(max(tmpHeight, minHeight), maxHeight) } } .onEnded{ value in os_log("END \(value.translation.height)") } ) Rectangle() .fill(Color.red) } } } } Here is the console output showing the value.translation.height flip flopping between -0.25 and +0.25. Hardware: MacBook Pro with Apple M1 Pro OS: Ventura 13.5.1

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 have a network system extension that sends flow records to my GUI app, and I saw an unusual string (%awdl0) appended to the local and remote IPv6 addresses in flow records from the UniversalControl program on my Intel iMac Pro. fe80::f42d:14ff:fe38:7db7%awdl0 fe80::18d7:9bff:feae:2e32%awdl0 Any idea why the suffix is appended to the IPv6 address and what it means? Here are more details about the event: { "localPort" : "56604", "socketProtocol" : 6, "version" : 0, "programLastComponent" : "UniversalControl", "localName" : "fe80::f42d:14ff:fe38:7db7%awdl0", "time" : 716847716.50096297, "socketType" : 1, "remotePort" : "57968", "socketFamily" : 30, "procInfo" : { "path" : "\/System\/Library\/CoreServices\/UniversalControl.app\/Contents\/MacOS\/UniversalControl", "lastComponent" : "UniversalControl", "teamId" : "", "signingId" : "" }, "timeStr" : "2023-09-19T20:21:56Z", "remoteName" : "fe80::18d7:9bff:feae:2e32%awdl0", "pid" : 667, "webHost" : "", "webUrl" : "" } And here is the flurry of flows reported including their ports: