Post

Replies

Boosts

Views

Created

Is "library-validation" implied by hardened runtime?
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!
2
0
220
Jul ’25
Where are 'socketfilterfw' changes being stored in macOS 15?
With the recent change to socketfilterfw in macOS 15 we can no longer check if the application firewall is enabled or not via a plist. This is significant in our app because we rely on the NSFilePresenter interface to monitor the plist to alert our app whenever a user changes their firewall settings. Removing the plist is a breaking change for us. Can you please advise either some new location on disk for us to monitor, or if there is another way to observe this setting? We would ideally rather not have to poll 'socketfilterfw' on an interval. Thanks!
2
0
2k
Jul ’24