Hello. I have an enterprise application that requires specific privileges to execute correctly on MacOS. One of these privileges is SystemPolicyAllFiles (aka Full Disk Access), as we use the endpoint security framework. When we distribute our application, we generate: A signed, notarized pkg consisting of our application binaries. An MDM-compatible .mobileconfig, which contains the SystemPolicyAllFiles setting. We expect our users to install both to get the application to function correctly. However, we have three environments we deploy to: Internal (local development on a developer's workstation), "development" (where features are integrated prior to release) and "production" (what our customers get). For local, our developers create an Apple account and use a Mac Development certificate for signing. They also generate their own embedded.provisionprofile and drop that into their local installation config. For development/production, we use our Developer ID certificate and Developer Installer certificate, with an endpoint security embedded.provisionprofile bound to those. However, when we generate a .mobileconfig, we need to include a CodeRequirement (CR) for SystemPolicyAllFiles. I've been retrieving this using codesign -dr - ... (i.e., the designated requirement aka DR). However, the designated requirement is very specific to the certificate, which is problematic specifically for local development, where each developer has their own Mac Development certificate. Here's what the relevant section of our generated mobileconfig looks like right now: <dict> <key>SystemPolicyAllFiles</key> <array> <dict> <key>Allowed</key> <true/> <key>CodeRequirement</key> <string>identifier "com.example.app and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = <TEAMID></string> <key>Comment</key> <string>app</string> <key>Identifier</key> <string>com.exmple.app</string> <key>IdentifierType</key> <string>bundleID</string> <key>StaticCode</key> <false/> </dict> </array> </dict> That's in a format that works for our Developer ID cert, but the DR for the Mac Development certificate looks like: identifier "com.example.app" and anchor apple generic and certificate leaf[subject.CN] = "Mac Developer: John Doe (12ABC34567)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */ Question: Is it possible to relax the code requirement so that it is generic enough to cover all Mac Developer certificates and Developer ID certificates we use? If not, is there a way to have one code requirement for our Mac Developer certificates and a separate CR for our Developer ID certificate? My use case is deploying a static "local" .mobileconfig using our internal company MDM (Apple Business Essentials) to all developer workstations so we don't have to have each developer manually configure their system for the software to run. Thanks! D

I have two privileged service(s) and a desktop app. The privileged services are packaged into /Library/*** and are run using launchd at runtime. The desktop app is just dropped into /Applications. The desktop app connects to one of the services (let's say service "B") via XPC. That is, B is running an XPC listener (using libxpc). Both applications are written in golang with xpc interaction via CGO. This is all working fine: The desktop app is receiving notifications over XPC from service B. However, during our build we dump the built and signed apps (before .pkg'ing) into a dist folder. When we run the app (using a makefile target), we copy the services from dist to another location as root, then execute the binaries directly. This is problematic for the desktop app, because my understanding is that XPC requires launchd to assert the namespace it's under. Thus, when service B is launched this way, it says "operation not permitted." We also want to reserve the ability to run a production version of our app on the same machine (drink our own champagne and all that), and I would like to avoid having development versions running on startup, so I don't want to use the same launch configurations. MacOS is one of three platforms we support (linux, windows as well). Our IPC implementation under MacOS uses XPC via golang build tags. Questions: Is it possible to start the XPC server without using launchd, or by using launchd but without registering it as an actual service? Is this a use case where using a unix domain socket would be better (albeit i feel like securing the socket between the privileged / unprivileged process would be ... fun). Additional / somewhat unrelated questions: is it possible for me to somehow restrict another process from chatting with service B over XPC (restrict to my other desktop app)? This is an app bundle question, so very unrelated: The service "app" that contains services A and B is in /Library, with the plist pointing to A, but B resides in Contents/MacOS next to A. Should this be split out into its own app bundle under Frameworks, or is this fine?

We have a MacOS application that we plan on distributing standalone (it'll be installed through MDM or directly, not through the app store). We utilize endpoint security and full disk access for this (enterprise) app. I have a makefile that uses codesign to sign the app inside-out. All that appears to work (i.e., when I try to run the app directly it functions as I expect it to). What's the recommended way to allow the developers in my team to also sign the app for local development so it functions as close as possible to production? My first thought is to distribute the developer identity to their machines using MDM. However, ideally i'd like to rule out the ability for a developer who has the MDM profile assigned to export the keys. That really only leaves a centralized solution in place or disabling SIP on their system (which I don't want to do). Alternatively, would creating a separate identity for production make more sense, so that in the case the developer certificate is revoked, the production releases continue to function as normal (however, I assume this would also require creating two different profiles for the endpoint security entitlement--one for each certificate). Thanks! Derek

Hello. I have a MacOS application to be distributed in a .pkg that is signed and notarized. For the application to work, it needs some settings defined by us (non-secret strings that differ per client). My thought has been to use a .mobileconfig to send these settings using the com.apple.ManagedClient.preferences PayloadType. I can see these settings land correctly into the /Library/Managed Preferences directory (in the correct domain) when distributed using Apple Business Essentials as the MDM. However, I cannot read the settings using NSUserDefaults OR CFPreferences in objective-c (i've tried with my app unsigned and signed, but not signed ant notarized so far). I've seen some posts here and there about managed preferences being deprecated, so I'm not sure if this is my issue or if i'm simply reading the preferences incorrectly. I'll admit the conflict of some of these posts has me a bit confused about how the preferences subsystem works / whether it should be used at all. I'm on MacOS 15.3. Two questions: Does anything stand out as to why I wouldn't be able to read these properties? Is there a better method I should be using to allow sending config via MDM to set application settings? Thanks in advance!