Changing entitlements of an app

Hi all,

I am trying to strengthen the security of a mac. I noticed that several applications do not have the sandbox capability, or they use a lot of the sandbox permission-adding entitlements.

For example pycharm on macOS adds the entitlement com.apple.security.cs.allow-unsigned-executable-memory which adds a security risk.

Is it a reasonable approach to modify the entitlements of a third party app to add the com.apple.security.app-sandbox entitlements and remove some permission-adding entitlements in the app? I am planning to modify the entitlements and then resign the app (I think the later step is necessary ).

Is that approach reasonable? I see that as a way to sandbox apps that the developer originally did not sandbox.

Thanks!

Replies

You are mixing up the App Sandbox and the hardened runtime. The com.apple.security.app-sandbox enables the App Sandbox, whereas com.apple.security.cs.allow-unsigned-executable-memory disables one of the security features that’s enabled by default by the hardened runtime.

However, speaking to your general question, it is possible to take a third-party app and re-sign it with your code signing identity. As part of that, you get to set various code signing options, including entitlements and the hardened runtime flag.

If you go down this path, make sure to re-sign any nested code, from the inside out.

However, there’s no guarantee that the resulting app will work:

  • If the app was from the Mac App Store, it definitely won’t work.

  • If you loosen security — for example, by disabling the hardened runtime — then you’re more likely to meet with success.

  • If you tighten security, you’re likely to run into problems. With specific reference to the App Sandbox, it turns on a wide variety of security measures and apps generally have to be reworked to account for those [1].

  • Some apps won’t tolerant re-signing no matter what you do. For example, if the app relies on a keychain access group and hard codes the Team ID prefix of that group — which is the standard thing to do — re-signing it as a different Team ID will prevent it from accessing that group.

Share and Enjoy

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

[1] Sometimes the rework is easy, sometimes it’s hard, sometimes it’s impossible, but there are always some changes.

I understand, thank you for your answer.

Regarding your point "make sure to re-sign any nested code, from the inside out" is it enough to use the "deep" option when doing so?

Specifically, is it good enough to use this command :

codesign -s $ID_NUM -f --deep --options runtime --entitlements new_entitlements.txt $APPLICATIONPATH

is it enough to use the "deep" option when doing so?

I generally recommend against that. See --deep Considered Harmful for an explanation as to why.

Share and Enjoy

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

Ah, that is good to know. Thank you.