An Apple, Inc. Sandbox to play in.

Published: 2011-11-03
Last Updated: 2011-11-03 23:37:33 UTC
by Richard Porter (Version: 1)
1 comment(s)


Today was a fairly slow *knock on wood* day on the Internet. Rare that we have business as usual, so in my normal readings I came across an article on how Apple, Inc. will require sandboxing [1] on all Apps posted to the Apple App Store by March 1, 2012 [2]. There is a lot of chatter on the Internet about this move. There are some pro's and con's to a move like this in my opinion. One clear Pro would be safer software (buyer beware as you have to trust Apple, Inc. Of course but…). One perceived con is lack of control over your operating system.

Sandboxing [5] [6], in short, is a method of creating a controlled container, if you will, for an application to run. A few popular applications use this method, including Chrome [7]. This controlled container's purpose is around mitigating the applications ability to make persistent changes to the operating system. Another common sandbox technique we often use is chroot [8] 

Part of last months Cyber Security Month, we covered critical controls. This move could attribute to a better implementation of CC 7?

How do our readers feel about this? Given there is an Apple, Inc. user population among us?


[1] (Warning Dev Account Required)



[4] (Source Article)






Richard Porter

--- ISC Handler on Duty 

email: richard at isc dot sans dot edu

twitter: packetalien

1 comment(s)


chroot is not a sandbox. Sandbox generally implies memory and process separation; all chroot does is change the "root" point for a running system. And that can be broken out of in various ways. It was originally intended primarily for development purposes, not production/security purposes. A bit about chroot:

BSD's do, however, have something like sandboxes in steroids called jails:

Diary Archives