RE: Sandboxing. WTF?
RE: Sandboxing. WTF?
- Subject: RE: Sandboxing. WTF?
- From: Shawn Bakhtiar <email@hidden>
- Date: Tue, 29 May 2012 22:15:56 -0400
- Importance: Normal
Just to make the point...
Linux has SELinux, which basically does the same thing. There are a set of ACL's and when an application tries to access files that are not part of its "Domain" SELinux does not allow it.
HOWEVER...
SELinux is an OPTION. It can be run in one of three ways. Enforcing, Permissive (which only does logging), and disabled.
The first thing 99.9 percent of admins do (it's almost in every setup SOP), is turn it to at least permissive if not disable it completely as most application do not run with it enabled. It is simply a cluster bomb that never worked, and it has been around for some time now.
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html
http://en.wikipedia.org/wiki/Security-Enhanced_Linux
Same thing, different names, in linux it's optional, in OS X (at least when it comes to app store) it seems not.
> From: email@hidden
> To: email@hidden
> Subject: RE: Sandboxing. WTF?
> Date: Tue, 29 May 2012 22:03:44 -0400
>
>
>
>
>
>
> I do tend to get melodramatic, for sure, as I truly love my 1s and 0s, and my love for them, makes me want to see them flow freely, unobtrusively, and have access to everything, an extension of myself on the users computer, helping him/her to get their work done. So sorry if it sounds like "torches and pitchforks" but that is not the point here.
>
> As for sentiment having anything to do with a technical mailing list, well, given the fact that we have had 3 (now 4) issues in as many days regarding Sandboxing, I believe the very technical solution, not using it, is a solution worth considering.
>
> Again, the technical answer (solution) is NOT to use it. If everyone on
> this list really understood the damage it does by turning people away from Apple (and the art of programing) many people, and acted accordingly, we can,
> and will change things. But simply saying it is what it is, is NOT an
> answer. Putting yourself in a prison (or you application in a prison)
> because there are a lot of bad people (applications) out there is not living (or in an
> application sense, executing).
>
> You can easily use torrent to distribute. Fedora Core and many open source products do so very easily. There are many MANY other avenues to expose yourself other then the app store, and if your business development team can not be creative enough to think of them, well maybe you need a new business development team :) The reality is some of the most highly productive application do NOT distribute via app store. EI SequalPro, VLC, Blender, etc....
>
> I really mean it, this is MCP. The Master Control Program from Tron. Please understand when you have a hardware vendor, riding an open source tool set, and creating control that as of yet no one has a good argument for, it should give everyone the creeps.
>
> Users will vote with their downloads, if a developer is a bad one and leaves his/her app vulnerable to other apps, then user will become wise, and stop using it. It is NOT the place of the hardware/OS vendor to be the cop. This is akin to the separation of church, state, and economy. You have the corporations running the government (in this case the OS provider telling the applications what to do).
>
> Again, the solution to the technical problems caused by sandboxing is to NOT use it, find other methods of distribution/advertising :)
>
>
> > Subject: Re: Sandboxing. WTF?
> > From: email@hidden
> > Date: Mon, 28 May 2012 17:43:26 -0500
> > CC: email@hidden
> > To: email@hidden
> >
> > On 28 May 2012, at 4:30 PM, Shawn Bakhtiar wrote:
> >
> > > First off (as much as I agree with the sentiment) isn't WTF profanity?
> >
> > Yes it is. Personally, I never use it, but I'll pass it unaltered to preserve mail threads or to quote accurately.
> >
> > > Second, and more to the point of my sentiment, and I hope someone on the Apple development team is reading this, have you people gone absolutely mad!
> >
> > 1. Sentiment isn't really what a technical mailing list is about. It's for mutual technical assistance, not torches and pitchforks.
> >
> > 2. There are some people from Apple who read these lists. They do so in their spare time. They are not in a position to influence policy. They do not generate bug reports from postings (go to bugreport.apple.com and file a report yourself). They are often very helpful, and flooding them with sentiments will just drive them away.
> >
> > 3. You're waking up nearly a year late. Apple documented this requirement last June. Apple has already been subjected to all the sentiment anyone can muster, and has made sandboxing entitlements more flexible in response. Sentiment, without documented use cases and concrete (I will add _informed_) suggestions for improvement, won't accomplish anything at this late date.
> >
> > > Thankfully I write apps for custom in-house applications so no big deal to me, but even if I had too, why in God's name would I distro via the app store, when I can simply setup an old fashioned download on an e-commerce site for my app?!
> >
> > Sandboxing isn't for everybody. Apple never said otherwise. As in so much of engineering, you choose your tradeoffs. If you can't sandbox, don't submit the app to the MAS.
> >
> > The tradeoff is that most developers don't have the resources to handle publicity, distribution, updates, or worldwide payments, and the MAS does those things for them. (You can afford time and money to do those things for yourself? Fine. Not everybody can eat cake.) The MAS makes more money for most developers. With sandboxing, it also provides customers more assurance than they otherwise would have that the apps they buy won't damage or steal their data.
> >
> > > it's a WHOLE other idea to have no technical users dealing with app signing issues, et al...
> >
> > Eh? The app is signed by the developer. Apple countersigns it. The user never sees a signature, except that breaking a signature will break the app. As far as it goes, that's a good thing.
> >
> > > how many Windows, Linux, etc, users actually get hacked via downloaded applications VS. going to some malicious website that uses OS/browser level vulnerabilities (how does sandboxing prevent, for example, flashback)? When 99% of all security breaches in companies are as a result of a disgruntled employee (from the inside), or sabotage (from the inside) what does sand-boxing REALLY prevent?
> > >
> > > Nothing. It prevents nothing.
> >
> > Sandboxing does not prevent determined attacks from hostile insiders. It is also COMPLETELY USELESS at promoting sound practices of regular oral hygiene. Suggesting a system is 100% useless if it isn't 100% miraculous is a strawman.
> >
> > My guess is that most of the real-world exposure Apple customers have is to Trojan applications, or applications that provide more capabilities to exploits than the apps themselves strictly need. Sandboxing an application mitigates the exposure through that app.
> >
> > Sandboxing isn't 100% miraculous. Individual developers will have perfectly legitimate reasons to do things that would be serious security holes if those things were allowed to everybody. Those legitimate features will be frozen out. The implementation will have bugs for years to come, and it is alarming that Apple saw nothing wrong with making it compulsory before completely thinking it out.
> >
> > Sandboxing can be an annoyance. But on its own terms, it's not an outrage. If you can't live with it, you're thrown back on distributing and selling your application yourself. Which is no worse than the position you were happy to be in a year ago.
> >
> > — F
> >
>
>
> _______________________________________________
>
> 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