SecCodeCreateWithXPCMessage: sender identity across concurrent receives, exec, and deferred replies

So, lemme share some factoids that I think it’s safe to rely on:

• XPC is based on top of Mach messaging [1].
• The audit token associated with an XPC message comes from the Mach message trailer.
• Which is set by the kernel when the client process sends the message.
• The audit token includes the pid (hence audit_token_to_pid), so calling fork (or posix_spawn) changes that.
• The audit token includes the pid version (audit_token_to_pidversion) and, less obviously [2], calling exec* changes that.

Given all of the above, I think you can answer your own question here (-: but if you have follow-up questions feel free to reply with them here.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Actually, there are variants of XPC that don’t use Mach messaging. However, these are not API, and if they ever do become API:

• I suspect they’ll be an opt in.
• But, regardless, the subtle details of audit tokens will be the least of your concerns (-:

[2] Consider this program:

#include <mach/mach.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <bsm/libbsm.h>
#include <mach-o/dyld.h>

int main(int argc, char **argv) {
    #pragma unused(argc)
    #pragma unused(argv)
    mach_msg_type_number_t count = TASK_AUDIT_TOKEN_COUNT;
    audit_token_t token = {};
    kern_return_t kr = task_info(mach_task_self(), TASK_AUDIT_TOKEN, (task_info_t) &token, &count);
    if ( (kr != KERN_SUCCESS) || (count != TASK_AUDIT_TOKEN_COUNT) ) { abort(); }
    char toolPath[PATH_MAX] = {};
    uint32_t toolPathSize = sizeof(toolPath);
    int ok = _NSGetExecutablePath(toolPath, &toolPathSize) >= 0;
    if (!ok) { abort(); }
    char * toolName = strrchr(toolPath, '/');
    if (toolName == NULL) {
        toolName = toolPath;
    } else {
        toolName = toolName + 1;
    }
    fprintf(stdout, "%s:\n", toolName);
    fprintf(stdout, "  pid: %d\n", (int) getpid());
    fprintf(stdout, "  audit token:");
    for (size_t i = 0; i < sizeof(token); i++) {
        uint8_t b = ((const uint8_t *) &token)[i];
        fprintf(stdout, "%02x", b);
    }
    fprintf(stdout, "\n");
    fprintf(stdout, "    pid: %d\n", (int) audit_token_to_pid(token));
    fprintf(stdout, "    pidversion: %d\n", (int) audit_token_to_pidversion(token));
    fprintf(stdout, "    asid: %d\n", (int) audit_token_to_asid(token));
    fprintf(stdout, "    auid: %d\n", (int) audit_token_to_auid(token));
    fprintf(stdout, "    egid: %d\n", (int) audit_token_to_egid(token));
    fprintf(stdout, "    euid: %d\n", (int) audit_token_to_euid(token));
    fprintf(stdout, "    rgid: %d\n", (int) audit_token_to_rgid(token));
    fprintf(stdout, "    ruid: %d\n", (int) audit_token_to_ruid(token));
    fflush(stdout);
    
    if (strcmp(toolName, "replacement") == 0) {
        return EXIT_SUCCESS;
    }
    char replacementPath[PATH_MAX] = {};
    strlcpy(replacementPath, toolPath, sizeof(replacementPath));
    char * slash = strrchr(replacementPath, '/');
    if (slash == NULL) { abort(); }
    slash[1] = 0;
    strlcat(replacementPath, "replacement", sizeof(replacementPath));
    // fprintf(stdout, "%s\n", replacementPath);
    char * replacementArgs[] = {
        replacementPath,
        NULL,
    };
    execv(replacementPath, replacementArgs);
    abort();
}

I built this into two different tools, original and replacement, and then ran the original tool:

% ./original
original:
  pid: 15579
  audit token: f6010000f601000014000000f601000014000000db3c0000b68601000cb30000
    pid: 15579
    pidversion: 45836
    asid: 100022
    auid: 502
    egid: 20
    euid: 502
    rgid: 20
    ruid: 502
replacement:
  pid: 15579
  audit token: f6010000f601000014000000f601000014000000db3c0000b68601000db30000
    pid: 15579
    pidversion: 45837
    asid: 100022
    auid: 502
    egid: 20
    euid: 502
    rgid: 20
    ruid: 502

Note that everything in the audit token stays the same except the pid version.

This is was using Xcode 27.1 or macOS 26.7.1, but AFAICT this behaviour has been consistent across all versions of macOS with audit token support.

Thanks, Quinn. That clarifies the kernel-supplied audit token and the PID-version change across exec.

Two points remain unclear:

1. For a retained received dictionary M, does SecCodeCreateWithXPCMessage(M, …) use identity fixed to that message’s original sender, even after concurrent receives or sender exec? The cited implementation’s connection-token lookup is what prompted this question.

2. Does retaining M’s reply context bind delivery to that original sending occurrence, or could a later executable or another rights holder receive the reply? If it doesn’t provide that guarantee, what supported public API and ownership pattern should validate the eventual recipient before sensitive data is sent?

Please identify any supported-version limits.