Blog headline image

Gatekeeper Keeps Some Gates Open (Still)

August 7th, 2012 by ‐ No Comments

Gatekeeper Icon (c) 2012 Apple, Inc.

While Apple is miles away from the former heights of the “Get a Mac” campaign with its new Genius TV ads (I fully concur with Ken Segall’s assessment that  this is a long time low in Apple’s TV ads btw.), Mountain Lion’s new Gatekeeper feature might still give the old “Get a Mac” security ad a whole new twist. Apple will want to be cautious to not overdo it when tightening security. But I’m sure they will observe the basic rule of secure system design: “Don’t try to be too secure.”

In updating the ComposeIT mail plug-in, we did however discover some things about Gatekeeper and sandboxing which we thought might be of interest. 

Our plug-in itself is not signed by default. So far we just didn’t need that. Out of curiosity, we upped the Gatekeeper strictness level to the most constrained (“App Store only”). And guess what? would load our unsigned plug-in just fine. So it seems that the restrictions only apply to application launching, not to bundle loading. is a sandboxed app, hence any adverse effects a malicious plugin might have, will be constrained to Mail’s sandbox. But Mail itself and the information it’s juggling (including email account passwords) might be at risk. We hope that Apple will extend the launching restrictions to loading of NSBundles in future OS X releases.

AppleScript Icon (c) Apple, Inc.

On a related note, the installer that comes with our plug-in is a compiled AppleScript. We use osacompile(1) to generate it. And guess what? Mountain Lion launches our unsigned installer without complaint. I assume that since even the compiled AppleScript is still an AppleScript (just in a binary encoding form) and is thus executed by an interpreter, it runs with the interpreter’s credentials (which of course is signed by Apple themselves). We hope that Apple will also be addressing loading of AppleScript in future OS X releases.

So at the first glance it seems that Gatekeeper is not as deeply embedded into the system as many might have thought. It seems to be a feature of the runtime environment setup (i.e. crt.o and friends), rather than of the process creation itself. But that was the case for FileVault a long time ago, too. Apple seems to be following the successful strategy of implementing a new feature outside the system core first, and only move it to the heart of the platform when it’s matured and well understood. So we think that OS X’s security features are just embarking on a long journey, and we’re curious to see where it will lead us.