Re: More sandblasting (oops, I mean sandboxing die die die)
Re: More sandblasting (oops, I mean sandboxing die die die)
- Subject: Re: More sandblasting (oops, I mean sandboxing die die die)
- From: Roland King <email@hidden>
- Date: Tue, 04 Sep 2012 06:57:32 +0800
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 <email@hidden> 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 <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden