Hi Everyone,
In libproc, there is a flavour for proc_pidinfo() PROC_PIDUNIQIDENTIFIERINFO, which as the name suggests, returns a struct of values that uniquely identify a process - more reliably than a pid.
In particular, it seems to have a 64 bit value that appears to be unique forever (or at least until system restart), thus shouldn't suffer from pid reuse races.
The problem is that this interface is gated behind #ifdef PRIVATE, and as such is pretty much the antithesis of 'published api'. So I guess my question is, is there a 'legit' way of accessing this value (or an equivalent) ? The call seems to work fine, and the number appears unique..
thanks, nick
So I guess my question remains - is there any other way to access this, and if not, is it possible to request that this become a public API?
So, there are a few different answers here:
-
What you're actually looking for is called an "audit token". I think PROC_PIDUNIQIDENTIFIERINFO is returning the audit token, but it's possible it's returning some other value derived from the audit token. Either way, you should be using the audit token, not PROC_PIDUNIQIDENTIFIERINFO.
-
As a general comment, the reason there isn't an obvious "audit token for PID" API is that this mapping process is inherently insecure— the primary reason audit tokens exist is to protect against PID reuse, but that also means the process of mapping a PID to an audit token is opening yourself to EXACTLY the attack audit tokens were created to defend against.
-
The more typical usage pattern is to retrieve the audit token of some existing object/connection (like a Mach port or an XPC connection), then use the audit token to retrieve other "information".
-
Having said that, even that case is not common, as most of our APIs tend to have higher-level mechanisms that are easier to use/more secure/etc. See this post about XPC validation for one example of this.
-
However, if you really want to get an audit token from a PID, this thread describes how to do so.
With all that context, let me jump back first to here:
So I guess my question remains - is there any other way to access this, and if not, is it possible to request that this become a public API?
I think the main question here is "what are you actually trying to do"?
Audit tokens are primarily used in lower-level system components that both need to track "lots" of processes AND aren't REALLY "interacting" with those processes. That last point is key because interactions between processes go over Mach/XPC, at which point the validations done in terms of the connection itself, not going back to the underlying process.
Similarly, I think part of the reason (aside from the obvious, "it would be a ton of work"...) is that using them as a security construct can be much trickier than it looks. For example, the EndpointSecurity API has its own structure it provides for describing processes. That structure includes the audit token but it also includes a number of code signing-related properties. That's mostly due to performance reasons, but also because the validation process itself has its own traps and pitfalls, since you can't just read the data off of disk (the running executable may already have been deleted).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
