These exact points are explained at the start of the 2012 WWDC sand boxing video, which also introduces some of the terminology and thinking behind the design. I found that video well worth 45 or so minutes of my life. Won't help with the sand boxing bugs but it did give me a better idea of how the Apple engineers think about sandboxing and some terms to search the docs for.
On 4 Sep, 2012, at 6:17 AM, Todd Heberlein <todd_heberl...@mac.com> wrote: > I suspect the moderator will shut this down as off topic, but I'll reiterate > what I've said before. > > On Sep 3, 2012, at 2:58 PM, William Squires <wsqui...@satx.rr.com> wrote: > >> Why should sandboxing on MacOS X even be necessary, seeing as we already >> have the Unix file permissions (and ACLs) to handle who can/cannot >> read/write to a file or directory? > > Case 1) To prevent your legitimate application with a vulnerability from > being used as an attack vector. > > Suppose you write a cool drawing program with your own file format. Your code > has a bug when parsing your document. An attacker constructors a malicious > document and sends it to one of your users. Your program reads the document, > and the malicious document drops a command & control agent on the user's > machine. > > This command & control agent has all the privileges you would normally have, > so it can send out all your email, all your email attachments, all your Pages > and Keynote documents, etc. > > In this way, sandboxing prevents us application developers from being > embarrassed by having our code compromise the user. This is probably the > primary benefit of sandboxing. You may want to sandbox your code even if you > distribute it outside the Mac App Store to avoid the embarrassment of being > used as an attack vector. > > I put together a video demonstrating exactly this type of attack (I've posted > it here before I think): > > Glowing Embers: The Myth of the Nation State Requirement > http://www.netsq.com/Podcasts/Data/2012/GlowingEmbers/ > > > Case 2) To prevent a malicious Trojan horse program from compromising the > system. > > Despite Apple's review process, they cannot detect malicious code buried > inside an application. Once accepted by the Mac App Store and installed on a > victim's computer, the evil application could silently (and perhaps slowly to > stay below the radar) exfiltrate the user's email, email attachments, Pages, > and Keynote documents. Again, it can do this because it runs with all the > user's normal privileges, and that is all it needs. > > > Todd > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
