Persistent “com.apple.security.get-task-allow” entitlement after signing¬arizing

Code Signing Entitlements
pymetin OP
Created
Replies 3
Boosts 0
Views 310
Participants 2

After signing and notarizing our application, the entitlement “com.apple.security.get-task-allow” is removed. However, we want this entitlement to remain and we want to be able to create a corefile when needed.

Is it possible to make the “com.apple.security.get-task-allow” entitlement persistent after signing and notarizing, so that our application can create a corefile?

Answered by DTS Engineer in 829923022
Is it possible to make the com.apple.security.get-task-allow entitlement persistent … ?

Yes. See the note at the bottom of the Avoid the get-task-allow entitlement section within Resolving common notarization issues.

IMPORTANT This disables important security protections in your product. It’s not something you want to do lightly. It might make sense to create a special version of your product that you only give to folks who need to create core dumps.

Also, disabling library validation makes it harder to pass Gatekeeper. See Resolving Gatekeeper Problems Caused by Dangling Load Command Paths.

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

Replies  3
Boosts 0
Views  310
Participants  2
DTS Engineer OP
Apple
Accepted Answer
Recommended
Is it possible to make the com.apple.security.get-task-allow entitlement persistent … ?

Yes. See the note at the bottom of the Avoid the get-task-allow entitlement section within Resolving common notarization issues.

IMPORTANT This disables important security protections in your product. It’s not something you want to do lightly. It might make sense to create a special version of your product that you only give to folks who need to create core dumps.

Also, disabling library validation makes it harder to pass Gatekeeper. See Resolving Gatekeeper Problems Caused by Dangling Load Command Paths.

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

DTS Engineer OP
Apple

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

Is this correct?

It depends on what you mean by “problems”. If you add the get-task-allow entitlement then you also have to add the com.apple.security.cs.disable-library-validation entitlement to disable library validation. That can then cause Gatekeeper problems, as I mentioned in previously. However, all of these problems are ultimately resolvable, meaning that it is possible to ship an app this way.

Whether it’s wise to ship an app this way is a different question. My earlier suggestion was to not ship that way by default but instead ship a special version that allows debugging. That way most users end up with the most secure version of your app.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
pymetin OP 
/usr/libexec/PlistBuddy -c "Add :com.apple.security.get-task-allow bool true" /tmp/my-app-debug-entitlements.plist
/usr/libexec/PlistBuddy -c "Add :com.apple.security.cs.disable-library-validation bool true" /tmp/my-app-debug-entitlements.plist
codesign --timestamp --options runtime --sign "Developer ID Application: *** (***)" --entitlements /tmp/my-app-debug-entitlements.plist --force /path/to/my-debug-binary

I had no problems with the notarization process of the binary I signed this way.

As you said, I will not distribute my application in this way. I will only distribute this binary to users I want to debug. Thanks.