Bugzilla

(In reply to wojciechregula from comment #8)
> (In reply to Haik Aftandilian [:haik] from comment #7)
> > I tested on macOS 10.15 and after changing the test code to use the correct Calculator path[1] on 10.15, the dylib still loads via DYLD_INSERT_LIBRARIES despite it not being signed. That need some more investigation.
> 
> Where did you find the information that, in the macOS 10.15, the injected dylibs have to be signed with a valid Developer ID? I only found info that the new checks will be performed on the first use when the app is quarantined. - https://developer.apple.com/videos/play/wwdc2019/701/
> 
> I took a screenshot of the new checks - https://i.imgur.com/PliPBFg.png 
> 
> Did I miss something?

I'm referring to Hardened Runtime restrictions on loading shared libraries. The documentation doesn't talk about injected dylibs specifically, but I was assuming the restrictions would apply to DYLD_INSERT_LIBRARIES. I don't know if Hardened Runtime is intended to prevent that or not. That's something we need to investigate.

As of 10.15, Hardened Runtime restrictions are enforced and an application signed with the "-o runtime" flag (or if its enabled with Xcode) can only load libraries signed by the same team ID as the binary. The ```com.apple.security.cs.disable-library-validation``` entitlement can be used to allow the application to load dylibs signed by other developers, but they do have to be signed.

On 10.15, applications are required to be notarized in order to launch (ignoring workarounds) and notarization is only allowed on apps with hardened runtime enabled.

On the blog post you referenced on comment 4, the author wrote they couldn't use DYLD_INSERT_LIBRARIES once they enabled hardened runtime until they signed the dylib. The error message they included has "Code has to be at least ad-hoc signed."

(In reply to wojciechregula from comment #8)
> (In reply to Haik Aftandilian [:haik] from comment #7)
> > I tested on macOS 10.15 and after changing the test code to use the correct Calculator path[1] on 10.15, the dylib still loads via DYLD_INSERT_LIBRARIES despite it not being signed. That need some more investigation.
> 
> Where did you find the information that, in the macOS 10.15, the injected dylibs have to be signed with a valid Developer ID? I only found info that the new checks will be performed on the first use when the app is quarantined. - https://developer.apple.com/videos/play/wwdc2019/701/
> 
> I took a screenshot of the new checks - https://i.imgur.com/PliPBFg.png 
> 
> Did I miss something?

I'm referring to Hardened Runtime restrictions on loading shared libraries. The documentation doesn't talk about injected dylibs specifically, but I was assuming the restrictions would apply to DYLD_INSERT_LIBRARIES. I don't know if Hardened Runtime is intended to prevent that or not. That's something we need to investigate.

As of 10.15, Hardened Runtime restrictions are enforced and an application signed with the "-o runtime" flag (or if its enabled with Xcode) can only load libraries signed by the same team ID as the application. The ```com.apple.security.cs.disable-library-validation``` entitlement can be used to allow the application to load dylibs signed by other developers, but they do have to be signed.

On 10.15, applications are required to be notarized in order to launch (ignoring workarounds) and notarization is only allowed on apps with hardened runtime enabled.

On the blog post you referenced on comment 4, the author wrote they couldn't use DYLD_INSERT_LIBRARIES once they enabled hardened runtime until they signed the dylib. The error message they included has "Code has to be at least ad-hoc signed."