Re: Sandboxing. WTF?
On May 29, 2012, at 8:03 PM, Shawn Bakhtiar wrote: The Master Control Program from Tron Could not agree with you more. Rather than abandon the App Store we are going to use it as a 'nose under the tent' … I cannot go into details but suffice it to say there are ways to use the ubiquity of the App Store without giving up your application's freedom. (Quote Braveheart here.) As you say, if we band together we can defeat Apple. I am all for it. Excellent post my friend. -koko ___ 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
Re: Sandboxing. WTF?
On May 29, 2012, at 7:17 AM, Mikkel Islay wrote: Shipley argues from the pretense that App Sandboxing is a technology intended to shield the user form the intentions of the software developer. That is of course not the case. From the docs: App Sandbox provides a last line of defense against stolen, corrupted, or deleted user data if malicious code exploits your app. Of course App Sandboxing will have bugs, and no doubt someone might write an arbitrarily sophisticated malware app which could make it past the review, but is that an argument against sandboxing? It is intended to secure apps (and users) after deployment. Recently someone posted a link to a blogpost, describing manipulation of the ObjC-runtime to attack third-party apps on compromised iOS-devices. App sandboxing is meant to limit the effectiveness of that type of attack on OS X. Is that a important or credible type of attack on OS X? Shipley's arguments all but ignores that question. It sounds like sandboxing would limit its effectiveness, but the fact that Apple is not sandboxing the majority of its own apps means there are still lots of opportunities for this kind of attack. Best, __jayson Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity at Work or School, So You Get The Grades, Raises and Promotions You Want. www.circusponies.com ___ 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
Re: Sandboxing. WTF?
On 2012-05-29, at 11:30 PM, Quincey Morris wrote: A number of commentators have jumped into the thread to declare, in effect, that the sandboxing could *never* work. Such a point of view seems inexplicably to ignore the fact that there is a platform out there already (iOS) for which sandboxing is demonstrably viable -- technically, economically, and functionally. iOS devices are successful but it's as easy to claim that it's in spite of an OS that is a functional failure as it is to give the OS any credit. Since people don't get to choose between increased flexibility and security, there's no way to know. The convoluted methods required when attempting to use two different apps when working with one document are strong evidence against functional viability from a *computing* perspective. Those devices make great media consumption tools but that's an awfully low setting of the bar if it's applied to real computers. ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 5:51 AM, Graham Cox graham@bigpond.com wrote: On 28/05/2012, at 7:31 PM, Roland King wrote: The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to th That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham ___ 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/darkshadow02%40mac.com This email sent to darkshado...@mac.com ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 5:51 AM, Graham Cox graham@bigpond.com wrote: That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham The CFPreferences... calls will actually take a path. Just give it the path where the bundle ID should go. This is not documented anywhere, but it works. If you'd rather not count on that always working, you don't have to parse the plist yourself, just read the plist in as data and use NSPropertyListSerialization (or CFPropertyList, if you need the CF calls for some reason) to parse it. (Sorry if a blank email also got sent; I fat-fingered something while selecting text on my iPad and am not sure if it sent or was canceled.) -- Michael Nickerson http://www.nightproductions.net ___ 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
Re: Sandboxing. WTF?
Le 30 mai 2012 à 16:56, Michael Nickerson a écrit : On May 28, 2012, at 5:51 AM, Graham Cox graham@bigpond.com wrote: That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham The CFPreferences... calls will actually take a path. Just give it the path where the bundle ID should go. This is not documented anywhere, but it works. If you'd rather not count on that always working, you don't have to parse the plist yourself, just read the plist in as data and use NSPropertyListSerialization (or CFPropertyList, if you need the CF calls for some reason) to parse it. -- Michael Nickerson http://www.nightproductions.net It does not solve the main issue. You assume the preferences are stored in property list, which is something not documented. Nothing prevent Apple to change it again to an other format that is not a property list, as the only documented way to access it is using CFPreferences/NSUserDefault API. -- Jean-Daniel ___ 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
Re: Sandboxing. WTF?
On May 29, 2012, at 8:03 PM, Shawn Bakhtiar wrote: 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. Modern operating systems have permissions systems, memory protection, and so forth. Arguments about the effectiveness of access control systems aside, users shouldn't be burdened with becoming security experts. Vulnerabilities are usually difficult to find, understand, and prevent. By become wise, you really mean that a user gets hit with an exploit and learns the hard way that an app is vulnerable. Preston ___ 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
Re: Sandboxing. WTF?
On 30 May 2012, at 16:07, Jean-Daniel Dupas wrote: Le 30 mai 2012 à 16:56, Michael Nickerson a écrit : It does not solve the main issue. You assume the preferences are stored in property list, which is something not documented. Nothing prevent Apple to change it again to an other format that is not a property list, as the only documented way to access it is using CFPreferences/NSUserDefault API. Nothing prevents Apple changing the keys they use within the defaults system either. ___ 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
Re: Sandboxing. WTF?
On May 29, 2012, at 9:30 PM, Quincey Morris wrote: A number of commentators have jumped into the thread to declare, in effect, that the sandboxing could *never* work. Such a point of view seems inexplicably to ignore the fact that there is a platform out there already (iOS) for which sandboxing is demonstrably viable -- technically, economically, and functionally. My response to such commentators is, of course: WTF? The problem is, OS X is a much more sophisticated platform than iOS. I'm not saying that sandboxing could never work; it works just fine in applications with simple needs, but more sophisticated apps often can't run in the sandbox. I know at least one of our products cannot be sandboxed, because it won't work without the ability to post HID events, something that Apple refuses to allow in sandboxed apps. For that reason, remote desktop servers also cannot run in the sandbox. Apps that rely on NSWorkspace for much of their functionality also can't run in the sandbox. And the list goes on... Nick Zitzmann http://www.chronosnet.com/ ___ 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
Re: Sandboxing. WTF?
But that is why not everything has to be sandboxed. For my mom I'd prefer apps to be sandboxed. For myself I'll have the variety of the internet plus what's on the App Store to choose from. I don't see the problem. Nobody is forcing you to sell on the App Store. Some apps simply won't work there. On May 30, 2012, at 4:00 PM, Nick Zitzmann wrote: The problem is, OS X is a much more sophisticated platform than iOS. I'm not saying that sandboxing could never work; it works just fine in applications with simple needs, but more sophisticated apps often can't run in the sandbox. Alex Kac - President and Founder Web Information Solutions, Inc. Patience is the companion of wisdom. --Anonymous ___ 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
Re: Sandboxing. WTF?
It would be true if Apple didn't start to limit availability of some API to sandboxed application distributed using the MAS. Le 30 mai 2012 à 23:20, Alex Kac a écrit : But that is why not everything has to be sandboxed. For my mom I'd prefer apps to be sandboxed. For myself I'll have the variety of the internet plus what's on the App Store to choose from. I don't see the problem. Nobody is forcing you to sell on the App Store. Some apps simply won't work there. On May 30, 2012, at 4:00 PM, Nick Zitzmann wrote: The problem is, OS X is a much more sophisticated platform than iOS. I'm not saying that sandboxing could never work; it works just fine in applications with simple needs, but more sophisticated apps often can't run in the sandbox. Alex Kac - President and Founder Web Information Solutions, Inc. Patience is the companion of wisdom. --Anonymous ___ 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/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ 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
Re: Sandboxing. WTF?
The only ones I know of are iCloud and gamecenter - stuff that works with their network. I can understand their thinking for that. On May 30, 2012, at 4:30 PM, Jean-Daniel Dupas wrote: It would be true if Apple didn't start to limit availability of some API to sandboxed application distributed using the MAS. ___ 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
Re: Sandboxing. WTF?
On 31/05/2012, at 12:56 AM, Michael Nickerson wrote: The CFPreferences... calls will actually take a path. Just give it the path where the bundle ID should go. This is not documented anywhere, but it works. Hmmm... well, relying on undocumented behaviour sounds like it could be a worse cure than the disease, but I'll experiment. If you'd rather not count on that always working, you don't have to parse the plist yourself, just read the plist in as data and use NSPropertyListSerialization (or CFPropertyList, if you need the CF calls for some reason) to parse it. Even easier is just to use [NSDictionary dictionaryWithContentsOfURL:] It does not solve the main issue. You assume the preferences are stored in property list, which is something not documented. Nothing prevent Apple to change it again to an other format that is not a property list, as the only documented way to access it is using CFPreferences/NSUserDefault API. True, and this is why the real solution is for Apple to give us an API for accessing iApps media files fully isolated from their implementation details. However, so many apps out there in the wild are doing this (either through Karelia's iMedia framework, or their own solutions) that Apple would be risking breaking a lot of apps unnecessarily if they were to make such a change without thought. While I wouldn't put it past them these days, they do have a fair track record of not breaking apps gratuitously. Also, there's no particular reason to change the format for plists which has been stable for a very long time. Much more likely is that keys in the preferences files could change, or that the name of the file could change, or its location. CFPreferences would dodge the last two, but nothing currently would be proof against the first one, and my app is just as weak as all the others in assuming the value of that key. All I can do is fail gracefully (I do) and expect to rev my app if and when iPhoto/iApps changes its disk layout. This is all now working with sandboxing enabled, though it feels like a pretty fragile pile of cards. I expect it to break. And there's still the question of whether the necessary temporary exemptions I need to get it past the sandbox demon (aptly named) will also be permitted by the App Store. --Graham ___ 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
Re: Sandboxing. WTF?
On 29 May 2012, at 01:59, Graham Cox wrote: Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html An interesting post, but his arguments against sandboxing, I think. Shipley argues from the pretense that App Sandboxing is a technology intended to shield the user form the intentions of the software developer. That is of course not the case. From the docs: App Sandbox provides a last line of defense against stolen, corrupted, or deleted user data if malicious code exploits your app. Of course App Sandboxing will have bugs, and no doubt someone might write an arbitrarily sophisticated malware app which could make it past the review, but is that an argument against sandboxing? It is intended to secure apps (and users) after deployment. Recently someone posted a link to a blogpost, describing manipulation of the ObjC-runtime to attack third-party apps on compromised iOS-devices. App sandboxing is meant to limit the effectiveness of that type of attack on OS X. Is that a important or credible type of attack on OS X? Shipley's arguments all but ignores that question. The post makes a lot of the weaknesses of app curation, but they are besides the point. The (relative) merits of sandboxing remain the same, irrespective of whether it functions in conjunction with the App Store or not. The argument that app curation is imperfect, doesn't impact the efficacy of sandboxing against attacks against apps. Using MacDefender as an example of malware, sandboxing does not deal with, is a bit of a straw man argument. MacDefender was a phishing scam. App Sandboxing is not particularly effective against programs designed to fool users into taking actions which are against their best interest. It was not really designed to be. Mikkel ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 8:49 PM, Graham Cox graham@bigpond.com wrote: The current implementation of sandboxing is extremely clunky, True. full of holes, Not so much. If anything it leans towards over-restrictiveness rather than errant permissiveness. and solves no real problems. False. It solves the problem of applications being unable to express their intended boundaries to the operating system. Without that information the OS can't help protect the user from malicious content or add-ons that will attempt to exploit the host app's lack of boundaries. If it were revoked tomorrow, I can't believe anybody here would mourn it - honestly? This current implementation? Probably not. A better implementation? Definitely. Security is one of those features you only care about when you notice it's missing. In the case of security, you usually notice when US-CERT sends out an advisory. --Kyle Sluder ___ 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
Re: Sandboxing. WTF?
On 2012-05-29, at 10:34 AM, Kyle Sluder wrote: It solves the problem of applications being unable to express their intended boundaries to the operating system. I'm honestly curious When did that become a real-world problem for Mac users? (And if it's anticipatory, what's different now that requires it?) I use, and program for, iOS. Mostly, I enjoy my iPad but there are days when sandboxing makes it seem more like a digital picture frame than a computing device. ___ 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
Re: Sandboxing. WTF?
Hear, hear. -koko On May 29, 2012, at 11:15 AM, Phillip Mills wrote: sandboxing makes it seem more like a digital picture frame than a computing device. ___ 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
Re: Sandboxing. WTF?
A long long time ago, we had getNetText and postNetText in Shockwave. We could save little text files in a specific folder. While the Sunder development, each shockwave movie had the option to exist in global space and have access to another SW movie's vars. Just to do a test of intermovie communication I did a simple polling set of routines to simulate a song playing back with a volume knob and a graphic equalizer back in 1996. http://www.director-online.com/buildArticle.php?id=37 http://web.archive.org/web/19991005142636/http://www.blacktop.com/zav/shockwave/ (I doubt this will even work today.) When this was done, we had turned off that option due to security concerns. We didn't even give a user an option to open it up so that multiple shockwave movies on a page could communicate without having to go through the file system. This was simply done to try to make sure that we didn't create a method for people to write viruses in Shockwave or mess with another movie running in another session without its permission. Sadly, I think that sandboxing is going to be a requirement in iOS (and Mac OS) for security reasons and for other system integrity reasons. On May 29, 2012, at 10:17 AM, Mikkel Islay wrote: On 29 May 2012, at 01:59, Graham Cox wrote: Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html An interesting post, but his arguments against sandboxing, I think. Shipley argues from the pretense that App Sandboxing is a technology intended to shield the user form the intentions of the software developer. That is of course not the case. From the docs: App Sandbox provides a last line of defense against stolen, corrupted, or deleted user data if malicious code exploits your app. Of course App Sandboxing will have bugs, and no doubt someone might write an arbitrarily sophisticated malware app which could make it past the review, but is that an argument against sandboxing? It is intended to secure apps (and users) after deployment. Recently someone posted a link to a blogpost, describing manipulation of the ObjC-runtime to attack third-party apps on compromised iOS-devices. App sandboxing is meant to limit the effectiveness of that type of attack on OS X. Is that a important or credible type of attack on OS X? Shipley's arguments all but ignores that question. The post makes a lot of the weaknesses of app curation, but they are besides the point. The (relative) merits of sandboxing remain the same, irrespective of whether it functions in conjunction with the App Store or not. The argument that app curation is imperfect, doesn't impact the efficacy of sandboxing against attacks against apps. Using MacDefender as an example of malware, sandboxing does not deal with, is a bit of a straw man argument. MacDefender was a phishing scam. App Sandboxing is not particularly effective against programs designed to fool users into taking actions which are against their best interest. It was not really designed to be. Mikkel ___ 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/zav%40mac.com This email sent to z...@mac.com ___ 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
Re: Sandboxing. WTF?
On May 29, 2012, at 5:51 PM, Alex Zavatone wrote: A long long time ago, we had getNetText and postNetText in Shockwave. We could save little text files in a specific folder. While the Sunder development, each shockwave movie had the option to exist in global space and have access to another SW movie's vars. Sorry, a bunch of my text got munched. While the Sunder development should read While the Shockwave plugin was under development. ___ 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
RE: Sandboxing. WTF?
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: fri...@manoverboard.org Date: Mon, 28 May 2012 17:43:26 -0500 CC: cocoa-dev@lists.apple.com To: shashan...@hotmail.com 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
RE: Sandboxing. WTF?
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: shashan...@hotmail.com To: cocoa-dev@lists.apple.com 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: fri...@manoverboard.org Date: Mon, 28 May 2012 17:43:26 -0500 CC: cocoa-dev@lists.apple.com To: shashan...@hotmail.com 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
Re: Sandboxing. WTF?
On May 29, 2012, at 19:03 , Shawn Bakhtiar wrote: 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). Nonsense. 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. Utter nonsense. The essence of this thread isn't about the philosophy of sandboxing. It's about the difficulty of *adding* sandboxing to an existing application with an established feature set. Mac applications often survive in niches, and invalidating functionality can have the side effect of ejecting applications from their niches. This is a valid and even vital concern to developers such as Graham. A number of commentators have jumped into the thread to declare, in effect, that the sandboxing could *never* work. Such a point of view seems inexplicably to ignore the fact that there is a platform out there already (iOS) for which sandboxing is demonstrably viable -- technically, economically, and functionally. My response to such commentators is, of course: WTF? ___ 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
Re: Sandboxing. WTF?
On May 27, 2012, at 22:40 , Graham Cox wrote: People will always click Allow if it gives them an easy life. Yes, and I think that's the potential weakness in Apple's sandbox-aware bookmark scheme. If you ask the user for permission, there's a good chance the user will just give it to you. I don't know of any solution to that, though I guess asking is better than not being forced to ask. Perhaps the app store review process takes note (or will take note) of such dialogs with the user, and rejects apps that seem to be asking for something egregious? ___ 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
Re: Sandboxing. WTF?
Le 28 mai 2012 à 07:18, Graham Cox a écrit : On 28/05/2012, at 3:10 PM, Marco S Hyman wrote: I think that is your issue. What is the issue? I have read that, several times. It states: With these provisos in mind, you can use a path-based temporary exception entitlement to gain programmatic access to the user’s ~/Library/Preferences folder. Use a read-only entitlement to avoid opening the user’s preferences to malicious exploitation. Well, that's what I am doing as I pointed out in my last message. But I still am unable to read the particular pref I need. (I have filed a radar asking that this feature be made available officially as well, but it's certainly a dupe). --Graham That's because you're not trying yo read ~/Library/Preferences/com.apple.iApps.plist but you are trying to read a preference file in your sandboxed application container. You just can't access file in ~/Library/Preferences using the CFPreferences API, as all calls to CFPreferences will be automagically redirected to you application container preferences folder instead. The posted documentation says: «A POSIX function, such as getpwuid, can provide the file system path you need.» I guess it means you have to resolve the real com.apple.iApps.plist path yourself and access the file directly. -- Jean-Daniel ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 6:54 PM, Jean-Daniel Dupas wrote: The posted documentation says: «A POSIX function, such as getpwuid, can provide the file system path you need.» I guess it means you have to resolve the real com.apple.iApps.plist path yourself and access the file directly. Okaaay That's a bit weird though, because you have to put the static file paths you want to access in your entitlements, but getpwuid is a function call, returning a path dynamically. Perhaps that path is actually static? Or do I call it and somehow register the entitlement on the fly? If so, how? It's documentation and commentary like this that is making it hard to adopt sandboxing. If they really want us to do it, why not spell it out instead of leaving us a trail of cryptic clues? --Graham ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 5:23 PM, Graham Cox wrote: On 28/05/2012, at 6:54 PM, Jean-Daniel Dupas wrote: The posted documentation says: «A POSIX function, such as getpwuid, can provide the file system path you need.» I guess it means you have to resolve the real com.apple.iApps.plist path yourself and access the file directly. Okaaay That's a bit weird though, because you have to put the static file paths you want to access in your entitlements, but getpwuid is a function call, returning a path dynamically. Perhaps that path is actually static? Or do I call it and somehow register the entitlement on the fly? If so, how? It's documentation and commentary like this that is making it hard to adopt sandboxing. If they really want us to do it, why not spell it out instead of leaving us a trail of cryptic clues? --Graham The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to that absolute path. ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 7:31 PM, Roland King wrote: The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to that absolute path. That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 5:51 PM, Graham Cox wrote: On 28/05/2012, at 7:31 PM, Roland King wrote: The way I read it is you register the entitlement exactly as you have been doing, as a user entitlement to Library/whatever. Then at runtime you use getpwuid() to find an absolute path to the actual user's home directory, construct the Library/whatever on top of that as an absolute (and of course dynamic depending on the user) path and open the file there. If my understanding is correct, the generic user entitlement you added will give you access to that absolute path. That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, just a bundle ID and key. I can't see an alternative API that takes a path - are you saying I have to open the file and parse it myself? While that isn't too hard, it seems to be going against the point of having an API for preferences which isolate you from format changes and file system details and so on. --Graham Again I've not done this - just reading and attempting comprehension - but yes in this case that's what I think you have to do. The CFPreferencesCopyAppValue indirects through the file path mapper and goes to the local sandboxed version of ~/Library which doesn't have the preferences file in it. You could I suppose find the real one and copy it into the sandboxed location at the right place, then use the API to read it, that might work. Yes I know that would stink up the code somewhat and is not a long-term solution to the problem. I'm with you on having the API point being a much better way, Apple now has to decide whether or not allowing that kind of access is something they will sanction, then they'll fix the API point to allow it, or else they'll say no. I don't think there was a full understanding, until people started trying this stuff, how many applications on OSX do reach all over the filesystem looking at stuff and how many apps just won't sandbox whilst retaining full functionality. From my reading of the dev forums, and boy there are some frustrated people over there, they are still trying to come up with a way which works. I'd have a go see if you can even make the path and access the file at all first, then we'll know if we have decoded the tech note properly. ___ 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
Re: Sandboxing. WTF?
On 28 May 2012, at 07:58, Quincey Morris wrote: On May 27, 2012, at 22:40 , Graham Cox wrote: People will always click Allow if it gives them an easy life. I don't know of any solution to that, though I guess asking is better than not being forced to ask. Perhaps the app store review process takes note (or will take note) of such dialogs with the user, and rejects apps that seem to be asking for something egregious? The obvious solution to that problem, then, is to rebrand users as malware too, and restrict their access to the system accordingly. :) It is striking that the source for apps Apple has the most control over (the App Store), imposes the most fine-grained restrictions, whereas non-App Store apps is/will be, able to get away with mere code-signing. If sandboxing is meant to secure the user, as you suggest, by treating garden variety apps as malware, and relying on the user to grant privileges to user data, it seems counter-productive to rely on those restrictions for App Store-apps, which will be considered intrinsically trust-worthy by most users. As you point out, software can be malicious entirely within the remit of its intended functionality. Rather, I think, sandboxing exists to limit the impact of malicious code manipulating the ObjC-runtime environment, and to limit Apple's liability (legal and perceived) for attacks against apps it distributes. Mikkel ___ 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
RE: Sandboxing. WTF?
First off (as much as I agree with the sentiment) isn't WTF profanity? 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! This is MCP to the max! 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?! Mark my words, to do this, will be the death of the App store. Users are fickle. make them irate and they WILL find a way around, and as several people have alluded to, user are notorious for clicking though (without reading or understanding) only to get what they want done. It's one thing to chroot an app on a server, where admins are the users, it's a WHOLE other idea to have no technical users dealing with app signing issues, et al... Perhaps instead of creating M$ like controls that have you clicking senselessly and endlessly to get something done, Apple should take a lesson from history. in other words, 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. It's nothing more then a warm fuzzy feeling, that actually makes things worse, because people start believing the hype, and relying on it as a method of security. So users become dumber, and take more risky action which then continues an ever tightening cycle (noose around the OS neck) of security, then one day, you go to log into your iMac and it asks for a blood sample. Boycott the App store I say, until Apple comes to its senses. Subject: Re: Sandboxing. WTF? From: my.inputstr...@googlemail.com Date: Mon, 28 May 2012 13:17:21 +0200 To: quinceymor...@rivergatesoftware.com CC: cocoa-dev@lists.apple.com On 28 May 2012, at 07:58, Quincey Morris wrote: On May 27, 2012, at 22:40 , Graham Cox wrote: People will always click Allow if it gives them an easy life. I don't know of any solution to that, though I guess asking is better than not being forced to ask. Perhaps the app store review process takes note (or will take note) of such dialogs with the user, and rejects apps that seem to be asking for something egregious? The obvious solution to that problem, then, is to rebrand users as malware too, and restrict their access to the system accordingly. :) It is striking that the source for apps Apple has the most control over (the App Store), imposes the most fine-grained restrictions, whereas non-App Store apps is/will be, able to get away with mere code-signing. If sandboxing is meant to secure the user, as you suggest, by treating garden variety apps as malware, and relying on the user to grant privileges to user data, it seems counter-productive to rely on those restrictions for App Store-apps, which will be considered intrinsically trust-worthy by most users. As you point out, software can be malicious entirely within the remit of its intended functionality. Rather, I think, sandboxing exists to limit the impact of malicious code manipulating the ObjC-runtime environment, and to limit Apple's liability (legal and perceived) for attacks against apps it distributes. Mikkel ___ 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/shashaness%40hotmail.com This email sent to shashan...@hotmail.com ___ 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
Re: Sandboxing. WTF?
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 (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
Re: Sandboxing. WTF?
On 29/05/2012, at 7:30 AM, Shawn Bakhtiar wrote: First off (as much as I agree with the sentiment) isn't WTF profanity? Well, it's in the eye of the beholder. I merely meant Where To Find (information) ;-) Mark my words, to do this, will be the death of the App store. Users are fickle. make them irate and they WILL find a way around, and as several people have alluded to, user are notorious for clicking though (without reading or understanding) only to get what they want done. It's one thing to chroot an app on a server, where admins are the users, it's a WHOLE other idea to have no technical users dealing with app signing issues, et al... Perhaps instead of creating M$ like controls that have you clicking senselessly and endlessly to get something done, Apple should take a lesson from history. in other words, 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. It's nothing more then a warm fuzzy feeling, that actually makes things worse, because people start believing the hype, and relying on it as a method of security. So users become dumber, and take more risky action which then continues an ever tightening cycle (noose around the OS neck) of security, then one day, you go to log into your iMac and it asks for a blood sample. Boycott the App store I say, until Apple comes to its senses. That isn't going to happen. I don't know about others' experiences with the App Store, but as an independent developer, it's been far more successful than we dared hope when it first opened. There's no way we could have done anywhere near as much business as we have, and withdrawing from it is only going to hurt us, not Apple. And that's if it even made sense to do so, which it doesn't - the horse is already out of the stable. If the App Store were launching tomorrow with this requirement such a boycott might stand a small chance. Sandboxing is a bit of a developer inconvenience, and while I tend to agree it really doesn't solve anything (or, it does, but the benefits are outweighed by the costs), it's not especially inconvenient for the user in the manner you're painting. In my case, assuming Apple are OK with the temporary exemptions to certain parts of the file system I'm asking for, the user will be none the wiser. In a few cases, where the user has put their iPhoto Library in a non-standard location, or has elected not to keep their photos in the iPhoto shoebox, I'll have to ask them if it's OK to peek at their iPhoto Library (or if their photos are all over the place, this would be unfeasible, so they'll just not be able to use that feature of our app). It's the usual 80/20% tradeoff - 80% of the users can be served without a hitch, leaving 20% with a few issues. Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. I'd have a go see if you can even make the path and access the file at all first, then we'll know if we have decoded the tech note properly. OK, back to the technical problem at hand. I have succeeded in getting this to work. I use getpwuid() to get the path to the user's home directory, append the standard location for the prefs file I want and I can read it into a NSDictionary (because I have the temporary exception privilege set). So that works alright - thanks for the help in getting me to understand what the documentation really is getting at. CFPreferencesCopyAppValue indirects through the file path mapper and goes to the local sandboxed version of ~/Library Yep, I see what's going on now. It's also why it was failing without a deny from sandboxd. What's annoying is that the parameters to this function give it enough information to realise that the intended file is outside of my sandbox (the fact that it's another app's ID) and could also isolate me in future from that app in itself being sandboxed. If iPhoto is sandboxed in future, its preferences will move and the getpwuid() technique will fail again. A correct fix to CFPreferencesCopyAppValue() would allow things to continue working seamlessly when that happens. Right now I have to look forward to my app breaking due to the fragility (and apparent lack of joined-up thinking) of this whole approach. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or
Re: Sandboxing. WTF?
On May 28, 2012, at 5:43 PM, Fritz Anderson wrote: 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.) I’m not sure the “Let them eat cake” thing really works for the MAS, since: - MacUpdate provides the same type of “publicity” that the MAS provides (better, in fact, since you get bumped back to the top each time you release an update), and it’s free. - Updates can be handled by Sparkle, which not only is both free and easy to set up, but which, unlike the MAS’s update scheme, *actually works* — your users will find out about updates when they use your app, as opposed to the App Store’s update scheme where you never find out about an updated version of an app until you happen to go to the App Store for some reason. I don’t know about you, but I rarely go to the App Store, and when I do, there’s usually a bunch of ancient unapplied app updates in there that I didn’t know about. I doubt most end users regularly check the App Store to see if any of their apps need updating. - Worldwide payments are already handled by services such as Kagi, eSellerate, et al., and they’re usually quite a bit *cheaper* than the MAS. The MAS only gets price-competitive with Kagi if the price of your app drops below $3.50 or so. Anything above that, and Kagi will be significantly less expensive. The only thing that’s legitimately more expensive when going non-MAS is getting a website for distribution, and a) web sites are cheap, b) if you move any kind of volume at all, their price will be easily dwarfed by the savings from not paying the App Store 30% of profits, and c) really, even if you’re going MAS, you’re going to want to have a web site anyway. I’m not really seeing the “cake” in non-MAS software development. Charles ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 7:23 PM, Charles Srstka wrote: The only thing that’s legitimately more expensive when going non-MAS is getting a website for distribution, and a) web sites are cheap, b) if you move any kind of volume at all, their price will be easily dwarfed by the savings from not paying the App Store 30% of profits, and c) really, even if you’re going MAS, you’re going to want to have a web site anyway. Actually, looking around a bit more, it turns out that eSellerate is able to handle distribution as well. Doing so requires their “Premium” plan, which bumps their fees from 5.9% to 8.9%, but that’s still worlds cheaper than the MAS’s 30%. Cake indeed. Charles ___ 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
Re: Sandboxing. WTF?
On May 28, 2012, at 7:59 PM, Graham Cox graham@bigpond.com wrote: Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. Uh, in 10.8 they implemented almost *exactly* the scheme Wil described: http://www.apple.com/macosx/mountain-lion/security.html --Kyle Sluder ___ 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
Re: Sandboxing. WTF?
On 29/05/2012, at 10:40 AM, Kyle Sluder wrote: On May 28, 2012, at 7:59 PM, Graham Cox graham@bigpond.com wrote: Nobody has written a better analysis, critique and alternative suggestion for sandboxing than Wil Shipley: http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html But Apple haven't taken any notice of this as far as anyone can tell, and that's that. We're stuck with it. Uh, in 10.8 they implemented almost *exactly* the scheme Wil described: http://www.apple.com/macosx/mountain-lion/security.html Yes, but *as well as* sandboxing, not instead of. The current implementation of sandboxing is extremely clunky, full of holes, and solves no real problems. If it were revoked tomorrow, I can't believe anybody here would mourn it - honestly? G. ___ 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
Sandboxing. WTF?
OK, none of us want it, it doesn't solve an actual problem, and it barely works. But we have to do it anyway. I turned on Sandboxing in my project and now I cannot run my app at all. This is logged: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, how do I fix it and how do I go about testing a sandboxed app during development? --Graham ___ 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
Re: Sandboxing. WTF?
On 27 May 2012, at 9:19 PM, Graham Cox wrote: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, how do I fix it and how do I go about testing a sandboxed app during development? Examine your entitlements file. If the entry the Gateway daemon complains of (com.apple.developer.ubiquity-container-identifiers) is there, delete it. I assume you aren't supporting iCloud. — F -- Fritz Anderson Xcode 4 Unleashed, making life worth living. http://x4u.manoverboard.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
Re: Sandboxing. WTF?
On May 27, 2012, at 10:19 PM, Graham Cox graham@bigpond.com wrote: I turned on Sandboxing in my project and now I cannot run my app at all. This is logged: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, You're using iCloud (which requires sandboxing) but the system can't verify your app's signature. how do I fix it Ensure your app is signed correctly and the correct provisioning profile is installed not only in Xcode but *also* in the Profiles System Preferences pane. This preference pane will not appear until the first profile is installed. To install profiles in System Preferences, double-click the profile in Finder, you can right-click the profile in the Xcode organizer to Reveal the profile in Finder. and how do I go about testing a sandboxed app during development? Once you get provisioning straightened out, debugging g and testing should be as normal. You need to make sure all testing machines are correctly provisioned as well, which means you are limited to a certain number of testing devices (100?). --Kyle Sluder ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 12:28 PM, Fritz Anderson wrote: On 27 May 2012, at 9:19 PM, Graham Cox wrote: 28/05/12 12:17:01.236 PM taskgated: killed my app[pid 1254] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What does it mean, how do I fix it and how do I go about testing a sandboxed app during development? Examine your entitlements file. If the entry the Gateway daemon complains of (com.apple.developer.ubiquity-container-identifiers) is there, delete it. I assume you aren't supporting iCloud. Ah, got it, thanks Fritz. I'm not using iCloud. In fact I was able to simply remove the iCloud Key-Value Store and iCloud Containers in the Entitlements UI in XCode and it's running. Sort of related question to the floor: The only feature of my app that is really affected by this is the ability to directly browse a user's iPhoto Library. I use elements of Karelia's iMedia framework to enable this, but sandboxing thwarts it, for fairly obvious reasons (iMedia peeks directly at iPhoto's preferences and grabs resources from the common frameworks used by iWork for icons and so on, as well as going into the iPhoto library itself for images). Our users love this feature. Has Apple given us a way to do it officially so we can keep our users happy while also toeing the line on sandboxing? If so, some pointers to that would be welcome at this point. If not, words fail me.. --Graham ___ 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
Re: Sandboxing. WTF?
On May 27, 2012, at 19:44 , Graham Cox wrote: The only feature of my app that is really affected by this is the ability to directly browse a user's iPhoto Library. I use elements of Karelia's iMedia framework to enable this, but sandboxing thwarts it, for fairly obvious reasons (iMedia peeks directly at iPhoto's preferences and grabs resources from the common frameworks used by iWork for icons and so on, as well as going into the iPhoto library itself for images). Our users love this feature. Has Apple given us a way to do it officially so we can keep our users happy while also toeing the line on sandboxing? If so, some pointers to that would be welcome at this point. AFAIK, the (a?) correct procedure is to ask the user to locate the items you want to reference, using the standard Open dialog. (This gives the user a chance to opt out.) From the result, you'll need to create a sandbox-bridging bookmark to the relevant authenticated URL, and store the bookmark in your own sandbox. Then, in future invocations of your app, you should be able to resolve the bookmark silently. The only fly in the ointment here is that the special bookmark requires a recent version of OS X. (I can't remember which one, perhaps it was 10.7.3.) On older versions, your only options would be to (a) withdraw the feature, or (b) ask the user the first time the reference is needed in each app invocation. (Well, the in the case of grabbing resources, you might be able to keep the resources themselves in your sandbox, and not have to go back to the source again.) If not, words fail me.. Well, I understand the frustration, but you *have* been getting somewhat of a free ride. You have (in effect, like a lot of us) been poking around in the user's file system and grabbing whatever you want. There's no *essential* difference between that and malware. That last statement has very sharp corners and is hard to swallow, but it seems inescapable if we are to have our security be actually, you know, secure. ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 1:42 PM, Quincey Morris wrote: On May 27, 2012, at 19:44 , Graham Cox wrote: The only feature of my app that is really affected by this is the ability to directly browse a user's iPhoto Library. I use elements of Karelia's iMedia framework to enable this, but sandboxing thwarts it, for fairly obvious reasons (iMedia peeks directly at iPhoto's preferences and grabs resources from the common frameworks used by iWork for icons and so on, as well as going into the iPhoto library itself for images). Our users love this feature. Has Apple given us a way to do it officially so we can keep our users happy while also toeing the line on sandboxing? If so, some pointers to that would be welcome at this point. AFAIK, the (a?) correct procedure is to ask the user to locate the items you want to reference, using the standard Open dialog. (This gives the user a chance to opt out.) From the result, you'll need to create a sandbox-bridging bookmark to the relevant authenticated URL, and store the bookmark in your own sandbox. Then, in future invocations of your app, you should be able to resolve the bookmark silently. The only fly in the ointment here is that the special bookmark requires a recent version of OS X. (I can't remember which one, perhaps it was 10.7.3.) On older versions, your only options would be to (a) withdraw the feature, or (b) ask the user the first time the reference is needed in each app invocation. (Well, the in the case of grabbing resources, you might be able to keep the resources themselves in your sandbox, and not have to go back to the source again.) OK, I've found some discussions and info elsewhere along these lines which gives me something to work on. I'm not against asking the user for permission to do this, as long as it doesn't become too intrusive. Currently though, my implementation falls at the first hurdle, which is here: CFArrayRef recentLibraries = CFPreferencesCopyAppValue((CFStringRef)@iPhotoRecentDatabases,(CFStringRef)@com.apple.iApps); This returns nil in the sandboxed version, even though I have added /Library/Preferences/com.apple.iApps.plist to my temporary exception entitlements (user relative, read only). Oddly, I do not get a sandboxd deny logged, which is why I was assuming it wasn't working at first. It must be something else, but it works just fine in the non-sandboxed app. Anyone else run into this? If not, words fail me.. Well, I understand the frustration, but you *have* been getting somewhat of a free ride. You have (in effect, like a lot of us) been poking around in the user's file system and grabbing whatever you want. There's no *essential* difference between that and malware. That last statement has very sharp corners and is hard to swallow, but it seems inescapable if we are to have our security be actually, you know, secure. Well, perhaps. But it's not really developers getting a free ride as much as users getting used to a nice feature that makes their apps easier to use. I'm far from the only app doing this, many do, and many integrate the entire iMedia browser to do it as well. I guess what pains me is that Apple have not as yet provided a sanctioned way to implement this feature. Maybe they will in future and I certainly hope so, but what's nasty about the current situation is that they have not made an officially sanctioned API available BEFORE imposing the sandboxing requirement on app developers. To me, that's pretty heavy-handed behaviour. I could understand it to a degree if there was a major issue right now with malware using this sort of thing to do its dirty work that needed to be shut down urgently, but AFAICS, it's a non-issue in practice. --Graham ___ 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
Re: Sandboxing. WTF?
On May 27, 2012, at 9:55 PM, Graham Cox wrote: Currently though, my implementation falls at the first hurdle, which is here: CFArrayRef recentLibraries = CFPreferencesCopyAppValue((CFStringRef)@iPhotoRecentDatabases,(CFStringRef)@com.apple.iApps); This returns nil in the sandboxed version, even though I have added /Library/Preferences/com.apple.iApps.plist to my temporary exception entitlements (user relative, read only). Oddly, I do not get a sandboxd deny logged, which is why I was assuming it wasn't working at first. It must be something else, but it works just fine in the non-sandboxed app. Anyone else run into this? AppSandboxDesignGuide.pdf says: == Accessing Preferences of Other Apps Because App Sandbox directs path-finding APIs to the container for your app, reading or writing to the user’s preferences takes place within the container. Preferences for other sandboxed apps are inaccessible. Preferences for apps that are not sandboxed are placed in the ~/Library/Preferences directory, which is also inaccessible to your sandboxed app. If your app requires access to another app’s preferences in order to function—for example, if it requires access to the playlists that a user has defined for iTunes—let Apple know about your needs using the Apple bug re- porting system. In addition, be sure to follow the guidance regarding entitlements provided on the iTunes Connect website. With these provisos in mind, you can use a path-based temporary exception entitlement to gain programmatic access to the user’s ~/Library/Preferences folder. Use a read-only entitlement to avoid opening the user’s preferences to malicious exploitation. A POSIX function, such as getpwuid, can provide the file system path you need. For details on entitlements, see Entitlement Key Reference . I think that is your issue. ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 3:10 PM, Marco S Hyman wrote: I think that is your issue. What is the issue? I have read that, several times. It states: With these provisos in mind, you can use a path-based temporary exception entitlement to gain programmatic access to the user’s ~/Library/Preferences folder. Use a read-only entitlement to avoid opening the user’s preferences to malicious exploitation. Well, that's what I am doing as I pointed out in my last message. But I still am unable to read the particular pref I need. (I have filed a radar asking that this feature be made available officially as well, but it's certainly a dupe). --Graham ___ 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
Re: Sandboxing. WTF?
On May 27, 2012, at 21:55 , Graham Cox wrote: users getting used to a nice feature that makes their apps easier to use Of course, but that's one of sharp, hard-to-swallow corners. Insecure is insecure. I guess what pains me is that Apple have not as yet provided a sanctioned way to implement this feature. AFAIK, you can still submit an un-sandboxed app and *request* an exemption until Apple provides an appropriate entitlement. Perhaps you might get it. Perhaps the need to access the iPhoto library might fall into this category. Perhaps Apple might ask if you submitted a bug report asking for a new kind of entitlement for your situation, sometime in the year or so since the sandboxing requirement was first announced. :) (I don't think the sandbox-aware bookmark thing was available till long after the original must-enable-sandboxing deadline of Nov 2011. I'm guessing it was only conceived after a bunch of complaints.) I could understand it to a degree if there was a major issue right now with malware using this sort of thing to do its dirty work that needed to be shut down urgently, but AFAICS, it's a non-issue in practice. You mean like uploading the user's entire iOS contacts DB to a developer's own server? Or storing the user's cell tower connection history in a file? Those made apps easier to use. Made lawyers richer, too. P.S. I'm not picking on your specifically. Call me a glass-quarter-full kind of person, but I think we (developers in general, over the past 50 years, not Mac developers specifically) have proved *repeatedly* that we can't be trusted to put user convenience first without creating truck-sized security holes. FWIW. ___ 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
Re: Sandboxing. WTF?
On 28/05/2012, at 3:23 PM, Quincey Morris wrote: You mean like uploading the user's entire iOS contacts DB to a developer's own server? Or storing the user's cell tower connection history in a file? Those made apps easier to use. Made lawyers richer, too. Well, those things happened on an OS that has had sandboxing from day one. It didn't stop it, did it? People will always click Allow if it gives them an easy life. --Graham ___ 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
