There is a moment in any system audit when the logs tell you who was responsible. On macOS, I found that moment is more nuanced than I expected — and that the nuance is, by Apple's own account, intentional.

The observation

When a process calls settid — the BSD syscall used to set a thread's identity — the kernel invokes the MAC policy hook mac_proc_check_settid. That hook receives two credential parameters: one representing the calling process's current credentials, and one representing the target thread's credentials. In cooperative threading patterns they can differ.

When they differ, auditing tools that read only one of the two parameters may attribute the operation to different identities — both technically correct, neither necessarily complete.

The PoC

# DTrace probe — mac_proc_check_settid credential divergence
# Own hardware only. Requires SRDP or partial SIP disable.
# Demonstrates when the two credential parameters differ.

sudo dtrace -n '
  mac_proc_check_settid:entry
  {
    printf("caller uid=%d  target uid=%d  match=%d\n",
           args[0]->cr_uid,   /* calling process cred */
           args[1]->cr_uid,   /* target thread cred */
           (args[0]->cr_uid == args[1]->cr_uid));
  }
' 2>/dev/null

# When the two UIDs differ: auditing tools reading only args[0]
# will log a different identity than tools reading args[1].
# Both values are factually correct — they describe different moments
# in the credential lifecycle.

Apple's response

"After investigation, this report described expected behavior, and doesn't demonstrate any control, data, or privilege gained by an attacker. As a result, it doesn't demonstrate a security issue."

I accept this. Apple's threat model is about control, data, and privilege. The dual-credential design does not give an attacker any of those things. The attacker who is already running code as the calling process does not gain new capabilities from the credential mismatch.

Why it is worth documenting

In the dot-com years I managed network estates across European data centres — Berlin, Budapest, Stockholm — often over early GPRS on Cellnet from trains. A recurring problem was not attackers but auditors: when something went wrong, the question of who had done what frequently came down to which system you queried and at what point in an authentication handoff. Two logs, both accurate, attributing the same operation to different identities.

The dual-credential architecture in mac_proc_check_settid is a precise version of that problem. Not a security gap. A thing that audit and forensic tooling authors should know exists.

Are you there? The thread said yes. It had been that identity since before you asked.