XCode not marked as is_platform_binary

is it because I downloaded it from the app store?

Yes. I’m a little hazy on the details but AFAIK is_platform_binary is only set on code that’s built in to the OS itself.

Also would checking for the com.apple prefix of the signing id be a good way to identify apple signed processes?

No. Consider:

% codesign -s - -i com.apple.finder -f test

Oh look, I’m the Finder!

The canonical way to test whether code is signed by Apple is using a code signing requirement:

% codesign -v -v --test-requirement "=anchor apple" test   
test: valid on disk
test: satisfies its Designated Requirement
test-requirement: code failed to satisfy specified code requirement(s)
%
% codesign -v -v --test-requirement "=anchor apple" /Applications/Xcode.app 
/Applications/Xcode.app: valid on disk
/Applications/Xcode.app: satisfies its Designated Requirement
/Applications/Xcode.app: explicit requirement satisfied

You can do this in code using the SecCode API.

For a big app like Xcode, this will be slow. You can cache the result using the cdhash as the key (this is the same key used by our notarisation system).

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

Quinn, as you said, for apps as big as XCode this can be very slow. I understand I can cache the result but if I am doing this in the context of an ES_EVENT_TYPE_AUTH_EXEC I would be blocking the first execution of Xcode for a long time before my analysis finishes. What would you do in my case?

What would you do in my case?

It’s hard to answer that without more context about your product. For example, if you’re product is aimed at managed environments you could reasonably a) expect that the system starts out ‘clean’, and b) allow the site admin to configure an allowlist of known good cdhashes.

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

So, given that, how -- and I realize this is a really broad question -- do you determine if an app's signature is, uh, legitimate?

I've stared at that for several minutes now; I know there's a big step I'm not taking to frame it correctly, and I think that would also answer it. 😄

Pardon me while I break down my thoughts a bit. A signature would be "uh, legitimate" if it is either signed by Apple, or signed by the team that said it did. (I mean, I assume I can't create a team called "com.apple.sean" or, I suppose more importantly, can't claim to be com.google and have an app called "Google Chrome" with a bundle identifier of, say, "com.kithrup.hahahaha.fooled.you" but a signing identifier of "com.google.chrome". It is an assumption.)

I can throw this in its own post and expand on my uncertain thoughts if that would be better.

how … do you determine if an app's signature is, uh, legitimate?

That depends on what you mean by “legitimate” (-:

Before we start I want you to read through the Code Signing Requirement Language section of the Code Signing Guide. I’m going to assume you understand that.

Also, the following is going to reference a whole bunch of oids that are specified by the various documents on the Apple PKI page.

There are four broad categories of code on the Mac:

• Built-in stuff

• Apple stuff that’s not built in

• Mac App Store apps

• Developer ID stuff

You can check for each of these using a code signing requirement. For example, consider the designated requirement on a Developer ID app:

% codesign -d -r - "Pacifist.app"
…
designated => anchor apple generic and 
    identifier "com.charlessoft.pacifist" and 
    (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 
        certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and 
        certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and 
        certificate leaf[subject.OU] = HRLUCP7QP4
    )

Note I’ve reflowed this to make it easier to read.

There’s three parts to this:

• identifier "com.charlessoft.pacifist" checks the code signing identifier.

• All the rest of the goo indicates two possible types of signing:

  • certificate leaf[field.1.2.840.113635.100.6.1.9] checks for Mac App Store signing.

  • The rest checks for Developer ID signing from a specific Team ID.

If you want to check for a Developer ID app but don’t care about the code signing identifier or the Team ID, build a requirement like this:

% cat DeveloperID-only.req
anchor apple generic and 
    (certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and 
     certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
    )

Now test it on various types of code:

% # Pacifist is Developer ID.
% 
% codesign -v -R DeveloperID-only.req -v "Pacifist.app"
…
Pacifist.app: explicit requirement satisfied
%
% # Tap Forms is Mac App Store, so not Developer ID.
% 
% codesign -v -R DeveloperID-only.req -v "Tap Forms 5.app"
…
test-requirement: code failed to satisfy specified code requirement(s)
% 
% # TextEdit is built in, so not Developer ID.
% 
% codesign -v -R DeveloperID-only.req -v "/System/Applications/TextEdit.app"
…
test-requirement: code failed to satisfy specified code requirement(s)
% 
% # Safari Technology Preview is not-built-in Apple, so still not Developer ID.
% 
% codesign -v -R DeveloperID-only.req -v "Safari Technology Preview.app"
…
test-requirement: code failed to satisfy specified code requirement(s)

Oh, one last thing: While I’m running these tests with the codesign tool, you can just as easily run them using SecCode APIs.

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