The criticism from Core Labs is that, whilst sandbox restrictions apply recursively to processes directly spawned by a sandboxed application, they don’t apply to processes spawned indirectly. The publicly-available documentation seems to consist only of how to use the five predefined profiles shown above, which are listed when you run man sandbox_init. Since entry-level developers can download and use Apple’s development tools, it would be a good idea to have them thinking about sandboxing for OS X software of any sort.

I’d love to summarise what “must implement sandboxing” means, but the relevant App Sandbox page isn’t open to the public, or even to entry-level Apple Developers.

This ought to allow the application to “promise” that, even in the presence of remote code execution bugs, it can’t be tricked by a hacker into providing network access.Īccording to Apple, anything sold or given away through the App Store “must implement sandboxing” by. The claimed vulnerability is in Apple’s much-vaunted sandbox, a kernel-enforced system of application restrictions which software can use to harden itself against attackers.įor example, an application which doesn’t have any networking code can voluntarily subject itself to the no-network (or kSBXProfileNoNetwork) profile.

In an article entitled A Tale of Two Advisories, the Core Labs researchers discuss vulnerabilities disclosed to Adobe and Apple, and the response of the two companies.Īdobe, apparently, reacted well. Argentinian security company Core Labs (which is the core research group, if you will pardon the pun, of US-based Core Security Technologies) has just published a critique of Apple’s attitude to security.

Apple sandbox cloud