Is "library-validation" implied by hardened runtime?

Question

Created Jul ’25

Replies 2

Boosts 0

Participants 2

We recently had an external pentest for one of our company's macOS applications and they brought up the topic of library validation. Our app has hardened runtime enabled and passes notarization. The codesign verification output includes:

flags=0x10000(runtime)

The pentesters brought up that both validation and runtime should be present, so I discovered that you could also add library validation by augmenting our flags with:

OTHER_CODE_SIGN_FLAGS = --timestamp -o library

which changes the flags to:

flags=0x12000(library-validation,runtime)

The pentesters insist that both options are necessary, especially to avoid library injection when SIP is off, but Apple's docs say that hardened runtime already implies library validation (see here )

My question is: does explicitly specifying library validation provide something that hardened runtime does not already? Or is it correct that hardened runtime already imply library validation?

For what it's worth, I did a quick scan of some of the apps on my system, interesting some of the Apple system apps have only library validation (e.g. Safari, Photos), some have both (e.g. Podcasts), some have only hardened runtime (e.g. Mail). So that didn't help answer the question.

Thank you!

Boost

Answer 1

dsg404 OP

Jul ’25

Couldn't figure out how to edit the post, but I forgot to mention that we don't include the com.apple.security.cs.disable-library-validation entitlement

0

Answer 2

DTS Engineer OP

Apple

Jul ’25

Recommended

I did a quick scan of some of the apps on my system

Just FYI, Apple apps won’t help you understand this issue because many of them are platform binaries [1] and platform binaries get library validation by default, regardless of their hardened runtime state.

does explicitly specifying library validation provide something that hardened runtime does not already?

No [2].

As long as you don’t use com.apple.security.cs.disable-library-validation to opt out of library validation, enabling the hardened runtime is all you need to do.

especially to avoid library injection when SIP is off

Have you tried to verify that claim? My understanding is that disabling SIP disables the underlying mechanism of library validation, and that takes effect regardless of how you enabled it.

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

[1] THe definition of platform binary is a complex one but, as a shorthand, you can think of it as anything built in to macOS.

[2] There’s one obscure case where setting the library validation flag and the hardened runtime flag can help. Old versions of Gatekeeper had a bug (r. 57278824) where they’d fail to recognise the implicit library validation enabled by the hardened runtime, and thus would block an app unnecessarily. You could work around that bug by setting both flags. However, that didn’t increase security, it just worked around a bug that would otherwise cause your app to be blocked by Gatekeeper.

IIRC this was in the 10.15-ish timeframe, so very early in our hardened runtime journey. If your app’s deployment target is macOS 10.15.7 or later, this is most definitely not a concern.

1