Apple Silicon Macs to Require Signed Code
New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature issued locally is sufficient, which includes signatures which are now generated automatically by the linker. This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Apple silicon Mac computers and enable the system to better detect code modifications.
This new policy doesn’t apply to translated x86 binaries running under Rosetta, nor does it apply to macOS 11 running on Intel platforms.
For Mail plug-ins, this is the third time signed code has become a requirement, with other times in between where it was forbidden.
Update (2020-08-24): See also: Hacker News, Reddit.
I wish they’d tell us specifically what attack vectors they’re protecting us from. Just a simple, real-world justification for why this is needed would go a long way towards assuaging our fears. Instead, it’s just “Trust us.”
I’ve been trying to figure out the benefits, and as far I can tell they only apply in very narrow circumstances. However, unless I’m missing something, the cost of requiring signed code is also very low.
Unlike developer signing and notarization, this isn’t intended to prevent any modifications being made to executable code. Malicious software could always re-sign modified code using another signature, although in doing so it would lose access to resources which were tied to the original signing identity, of course. But it’s intended to significantly reduce the surface area of attacks.
Previously:
Update (2021-06-29): Alexandre Mutel:
The Burst team is fighting M1 support, awful platform to work with, requiring us to codesign native code... so every single piece of code that Burst produce has to go through a stupid codesign external exe to patch it... currently making Burst compiler x5 slower* on M1
4 Comments RSS · Twitter
You omitted the part (in the previous paragraph) where Xcode 12b4 will automatically sign code when it’s linked, and this ad-hoc signing is sufficient to pass the Gatekeeper check. I understand the concern, but assuming Apple gets this right (sadly no longer a given), this ought to protect against tampering with the executable binary and no more... or am I missing something?
@rsfinn In case it goes away, the preceding paragraph is:
Starting with Xcode 12 beta 4, the toolchain will now automatically sign your executables whenever you build from Xcode, or use command-line utilities such as clang(1) or ld(1). This new mechanism generates signatures directly at link time, and doesnʼt cover any resource other than the executable. As a result, itʼs expected to be faster than a traditional codesign(1) invocation. If you use a custom workflow involving tools that modify a binary after linking (e.g. strip or install_name_tool) you might need to manually call codesign(1) as an additional build phase to properly ad-hoc sign your binary.
I don’t think it’s correct that the ad-hoc signing is sufficient to pass Gatekeeper, since the binary would not have a Developer ID certificate associated with it, and it would not be notarized. I guess it’s just to protect binaries that you compile and use on your own Mac. I don’t really understand in what situation they could get tampered with and not simply re-signed (to prevent the tampering from being detected).
I don’t really understand in what situation they could get tampered with and not simply re-signed
Maybe it isn’t about security so much as loading efficiency: if you can guarantee that nothing inside the bundle changes from the moment the bundle is launched, you can cache portions, move them elsewhere (app translocation), etc., without any need to check for atomicity.
