I’m designing a least-privilege system LaunchDaemon registered with SMAppService, and I’d like to clarify whether the following architecture is supported by public macOS contracts.
The LaunchDaemon declares a MachServices entry. Its steady-state service must run as a dedicated non-root account and later creates an NSXPCListener for that Mach service.
We currently launch the daemon directly using UserName, GroupName, and InitGroups=false.
However, InitGroups=false does not appear to guarantee that the resulting process supplementary-group list is limited to the service’s intended group. In testing, the daemon received a supplementary group outside our accepted set.
We therefore do not want to depend on incidental inherited launch-time group state.
We are considering this alternative:
-
launchd starts a small, fixed, code-signed bootstrap executable as root.
-
The bootstrap reads the target UID/GID from an existing protected root-owned binding record.
-
It establishes an exact credential state using public BSD APIs, conceptually:
setgroups(...) setgid(...) setuid(...)
-
It verifies the resulting non-root credentials.
-
It creates no XPC listener or storage connection while privileged.
-
Without forking, it permanently replaces itself using execve() (or possibly POSIX_SPAWN_SETEXEC) with another fixed, separately signed executable in the same bundle.
-
That non-root executable independently validates its security state and then creates NSXPCListener(machServiceName:) for the Mach service declared by the original LaunchDaemon job.
The bootstrap would not remain as a privileged parent or supervisor.
My main questions are:
-
Is a same-PID exec after permanent UID/GID/supplementary-group reduction supported for an SMAppService system LaunchDaemon before it checks in to its declared Mach service?
-
Does the exec-replaced process retain the launchd/bootstrap context required for NSXPCListener(machServiceName:) to check in to that Mach service?
-
If so, what execution context must be preserved across exec (for example bootstrap context, environment, file descriptors, or Mach rights)?
-
Is there a documented way to preserve only the context required for the LaunchDaemon/Mach-service relationship without carrying unintended root-derived capabilities into the non-root executable?
-
Would SMAppService.unregister() / normal launchd termination continue to treat the exec-replaced process as the same LaunchDaemon job?
If this topology is not supported, is there an Apple-supported way to establish an exact supplementary-group set before a non-root SMAppService LaunchDaemon begins handling its Mach service?
The goal is to avoid relying on undocumented launchd behavior, incidental supplementary groups, private APIs, or a long-lived privileged helper.
I’m specifically looking for the supported contract here rather than whether this happens to work on a particular macOS release.
The reason I was considering two executables was purely to minimize the amount of application code that ever runs as root.
OK. That’s a worthy goal, but I think it engenders too much risk in this case.
One alternative would be to move this code into a shared library that the main tool loads after dropping its privileges. That makes it easy to audit that the main tool can’t do any XPC before that transition.
Is that single-process pattern supported for an SMAppService LaunchDaemon with a declared MachServices entry?
It’s hard to guarantee that. Your plan is reasonable enough — specifically, Mach IPC is capability based, so it won’t be affected by changes to your BSD privileges — but it’s still weird, and weird stuff is more likely to break that standard stuff. However, I think it represents a reasonable compromise between your security goals and compatibility risk.
Regardless of what else you do, I recommend that you file an enhancement request against launchd for a property that causes it to do this work instead of your. And please post that bug number, just for the record
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"