Can one use the new provenance feature to avoid slow notarization checks for newly compiled unsigned binaries?

I am working with a compiler that produces native binaries, It's really meant for servers so it's not integrated with Xcode or the Xcode build system. As such the output binaries get the default ad-hoc signatures the linker makes.

After (re)compiling such a binary, there is a delay whilst running it. This is because macOS notices it's an unknown binary and goes off to ask notarization servers/Xprotect if it's known malware. Fine, I understand the need for this and why it happens.

From the logs it's clear that macOS is now tracking the "provenance" of binaries. This means where they came from. This raises the question of whether it could know that my local dev binaries are coming from this compiler, if it was in turn properly signed and notarized. And if so, whether there is some security policy I could set to say "if binary X produces binary Y, then trust Y".

Yes I know this would be a security exploit if it were done that way by default, but I am willing to take the risk of special malware that compiles itself first using this special compiler that isn't installed by default then runs the output, as presumably any such malware would be so targeted Xprotect/notarization wouldn't know about it anyway.

The provenance mechanism is some internal security thing and isn't documented, but I'm curious if anyone knows more about it and whether it's usable for this? Or alternatively if there's a way to stop macOS doing these slow checks for certain binaries e.g. under specific paths?

Have you looked at the Execution Policy framework?

To be honestly, I’ve never looked at this in depth myself )-: but it seems like a good fit for your setup.

Share and Enjoy

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

That certainly sounds relevant, thanks!

But ... the API is undocumented and appears to exist only for Xcode. There's exactly one hit for it on Google, which is this very helpful thread from someone who got a 1:1 tutorial in how to use it from Apple's security team!

https://developer.apple.com/forums/thread/650695

I'm not sure how to interpret that. Are we allowed to use this API? Nobody seems to have objected to Jeff's thread on this forum, but nor does it seem like we're really meant to be using this.

Some questions I'd have if it were to be documented:

  • Is this usable for non-bundled binaries?
  • If it's bundled, do you pass the URL of the bundle, or of the main binary?
  • Does the target binary have to be fully signed, or is ad-hoc signed sufficient?
  • Does it affect POSIX launches, like from a shell? Or does it only work for stuff launched via launch services? As kernel/notarization/syspolicyd is invoked by the kernel I'd hope that it does work for POSIX launches but Jeff's thread only talks about NSTask and other Mac specific APIs.
  • Does it keep working if the file is moved or copied? Probably not, as the exception is URL based.
  • How does it work for the non-IDE use case? Should the terminal app itself be added as a developer tool? That seems a bit loose... I'm not averse to having Apple check my parachute lines from time to time, especially as us developers like to do do disgustingly promiscuous things like curl|bash or brew install xyz without thinking. Or maybe if the compiler is signed it can invoke this API to exclude the output file automatically.

Really, it feels like this should be done by the system ld. Xcode is already set up as a developer tool. There's nothing really special about this compiler and it lets the Apple toolchain finish off the binary.

Hmm. Not for the first time I find myself wishing the sandboxing stuff was more user exposed so I could define "domains" to keep developer/CLI stuff separated and confined. Maybe a product idea is born :)

Can one use the new provenance feature to avoid slow notarization checks for newly compiled unsigned binaries?
 
 
Q