Hey,
Just recently I realized something I have been overlooking in my build pipelines.
I thought that by adding the the "hardened runtime", I disable 3rd-party library injection (I do not have the disable-library-validation entitlement added).
However, I was using some checks on my code and I noticed that the "library validation" code signature check fails on my applications (e.g. adding the .libraryValidation requirement via the LightweightCodeRequirements framework) - with codesign -dvvvv /path/to/app I can check it doesn't have the CS_REQUIRE_LV flag:
[...]
CodeDirectory v=20500 size=937 flags=0x10000(runtime) hashes=18+7 location=embedded
[...]
then I used in Xcode the "Other Code Signing Flags" setting and added the -o library option, which added the flag:
[...]
CodeDirectory v=20500 size=937 flags=0x12000(library-validation,runtime) hashes=18+7 location=embedded
[...]
Is this flag something I should be explicitly setting? Because I was under the impression enabling hardened runtime would be enough. Popular Developer ID distributed applications (e.g. Google Chrome, Parallels Desktop, Slack) all have this flag set.
Is this flag something I should be explicitly setting?
Probably not.
Library validation is implicitly enabled by the hardened runtime [1]. If you have that set, there’s no security benefit from enabling library validation explicitly.
OTOH, it won’t cause any problems either.
There are a few situations where having both flags is a benefit:
- If you run on systems prior to macOS 10.14, where the hardened runtime was introduced [2].
- In macOS 10.15.x, x < 4, there was a Gatekeeper bug (r. 57278824) that you could workaround by explicitly enabling library validation.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Unless you then opt out of it via the com.apple.security.cs.disable-library-validation.
[2] I suspect that’s why various apps have it set. They added in back in the day and no one has got around to removing it.