Does signed macho binary with teamID is signed by Apple root certificate

I’m confused. To start, I’m concerned about this path:

I decided to rely only on the Team Identifier.

I don’t understand how you can trust anything about the code signature, and that includes the Team ID, if you don’t first validate the code signature.

Next, in cases like this I usually ask about the big picture. And on that subject you wrote:

In my application I validate the authenticity of my own binaries

Programs can’t authenticate themselves. If an attacker is able to modify your code, they can also remove or subvert any checks that you add.

What problem are you trying to solve here?

ps On iOS I usually point folks at App Attest, but I’m presuming that you’re on the Mac.

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

Regarding Programs can’t authenticate themselves. I don't try to authenticate my own executable, I am trying to verify a helper binary/dylib inside my product that can be updated separately from the main binary.

Before running/dlopening it, I would like to ensure:

Test 1) The signature chain of the executable/dylib leads to the apple root.

Test 2) The leaf certificate team-id is my team-id.

Per my understanding this will ensure that this executable/binary was signed by me.

If anyone else has a valid certificate(it can pass Test 1) but it will fail the Test 2 as its team ID will be different.

If someone crafts a rogue certificate in order to pass Test 2 then this rogue certificate is not signed by apple and therefore will fail Test 1.

Please advise if you see any problem with this approach.

Now to my main question: When I try to extract the team id from the executable/dylib using SecCodeCopySigningInformation, I see some posts claim that if that executable is not signed by apple root chain team-id will come up as empty.

I therefore ask:

Approach 1: Is it enough to extract the team-id and compare to mine ? Does extracting a team-id(using SecCodeCopySigningInformation) automatically verifies that the anchor is apple ?

OR

Approach 2: Should I extract the team-id and compare it to mine AND in addition, manually verify the that anchor/root is apple ?

I currently did "Approach 2" but it seems when I am trying to verify the anchor it sometimes takes several minutes for some reason and I see:

trustd: [com.apple.securityd:SecError] Malformed anchor records, not an array

Printed in the logs.

I therefore wonder if its required at all.

I am trying to verify a helper binary/dylib inside my product that can be updated separately from the main binary.

Is this an executable or a dynamic library? Or do you need this test to support both?

And by “inside my product” do you mean that it’s located within an app’s bundle? Or that it’s logically part of your product, but is stored in some other location on disk?

And while I’ll have a lot more to say about your overall issue once I better understand it, I want to nip this one in the bud:

Does extracting a team-id … automatically verifies that the anchor is apple?

No. You can’t trust the information you get back from SecCodeCopySigningInformation unless you’ve validated the code signature.

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

Hi @DTS Engineer , I need to support both use case (exec and dylib). As for the library case, I’m aware that macOS provides built-in validation to ensure a library and the loading binary are signed with the same certificate, this does not apply in my scenario since the library is provided by a third party.

So I've disabled the default library validation via the entitlement com.apple.security.cs.disable-library-validation, and instead perform my own certificate validation logic within the application code.

I need to support both use case (exec and dylib).

OK.

[Library validation] does not apply in my scenario since the library is provided by a third party

I’d like to better understand that. It’s quite common for Mac apps to use libraries created by other developers, and they retain library validation by re-signing those libraries. Is there something preventing you from doing that in this case?

The most obvious case where folks need to disable library validation is that their app supports in-process plug-ins, where those plug-ins are built and shipped by other third-party developers in a way that’s completely independent of the main app’s vendor. Is that what’s happening here?

Because if you’re managing these plug-in releases then it’d be better to have you re-sign the plug-in and leave library validation enabled.

And that brings me back to your Team ID requirement. Do you accept code from a small set of teams that you know in advance? Or do you learn about the Team ID via some other channel?

The reason I ask is that we have a relative new option here, the ability to restrict libraries to a specific set of teams. See Applying launch environment and library constraints.

Still, all of the above is only relevant for libraries, and you also have executables to deal with.

Which brings me back to the point where you departed from the well-trodden path, namely, the time taken to verify a code signature.

Verifying a code signature can take a while. The canonical example of this is Xcode:

% /usr/bin/time codesign -v --deep --strict "/Applications/Xcode.app"
       12.73 real        11.09 user        88.21 sys

However, verifying a less massive app is typically pretty quick:

% /usr/bin/time codesign -v --deep --strict "/Applications/Apple Configurator.app"
        0.27 real         0.19 user         1.43 sys

In your case it’s taking minutes, which suggests that either the thing you’re verifying is huge or something is going wrong. How big is the code you’re verifying?

And if you verify the same code using codesign from Terminal, as I’ve shown above, does it have the same problem?

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