Bundle ID vs signing identifier

NEFlowMetaData has sourceAppSigningIdentifier -- but that doesn't have to be the bundle identifier, correct?

Correct. Indeed, this came up just a few days ago.

So is there a way to go from one to the other?

Kinda. What are you trying to do here? ’cause on the Mac neither the bundle identifier nor the code signing identifier can be trusted [1], which means a security product probably shouldn’t be looking at them at all.

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

[1] By itself. To identify code you typically look at its code signing designated requirement. This has the code signing identifier embedded within it, but it also has extra info that identifies the team, and it’s that combo that you need.

Mostly I'm playing around here -- I wanted to log if that sort of discrepancy came up. And then I wanted to find the path to the possibly-offending process, and flag it for examination. And I knew I could go from bundle ID to path, and vice versa, and that was the reason I was asking.

Also... if the code signing identifier can't be trusted, why is that what the OS gives network extensions? (I guess it also gives the audit token, but that's opaque and I'm still not clear on what is and is not supposed to be obtainable from it. :))

And then I wanted to find the path to the possibly-offending process, and flag it for examination.

OK. In that case you should go from the audit token (sourceAppAuditToken) to a SecCode object and then get information from there. The code in this post will get you started.

if the code signing identifier can't be trusted, why is that what the OS gives network extensions?

Because NEFlowMetaData originated on iOS where the code signing identifier can be trusted.

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

Because NEFlowMetaData originated on iOS where the code signing identifier can be trusted.

Ok that actually occurred to me last night as I was unable to sleep. 😄

The NE flow metadata also has the sourceAppUniqueIdentifier -- I assume there's a way to go from a filesystem path to that? One of your posts mentions a cdhash which I presumed was the same thing, but I didn't see how to get either one.

Thanks!

I assume there's a way to go from a filesystem path to that?

No.

To get the path, map the audit token to a code object and get the path from that (SecCodeCopyPath).

One of your posts mentions a cdhash which I presumed was the same thing

I just did a quick check and, as things are currently implemented, sourceAppUniqueIdentifier is indeed the app’s cdhash. However, as that equivalence isn’t documented I wouldn’t rely on it. If you want to get the cdhash specifically, map the audit token to a code object and then get the cdhash from that (kSecCodeInfoUnique or, if you want to get really fancy, kSecCodeInfoCdHashes).

You can use the audit token as a cache key to avoid taking these slow paths every time.

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

You can use the audit token as a cache key to avoid taking these slow paths every time.

Yeah, my experimental setup uses multiple processes (why? Because I am experimenting in it 😄), so one thing I was thinking of trying would be used for a block/allow list, and have the C&C process say "This app/executable is going to be treated differently somehow," and then send that down to the provider, to use for cache checking. (Rather than doing it in the provider, which I already think takes way too long, which is why I am also playing around with Instruments.)

But it looks like I can't safely/reliably do that.