Inside Sandboxing: how Apple plans to make the Mac App Store as secure as iOS - Page 2

After reading through the basic developer documentation on App Sandbox, it's mostly sandbox with fine-grained permissions to reach outside with a few capability-based security style features, notably the Powerbox. Fine-grained permissions systems tend to be a pain for developers which leads to their effective security to be less than their potentially achievable security as developers simply request more permissions than they actually need (though Apple as application auditor will probably provide pressure to reduce unneeded permissions). Also, the permissions are almost all static rather than dynamic, also leading to more permissions than required at any point in time.

The main exceptions are due to the Powerbox (the capability-based security bit), which are nearly transparent to the developer and user and provide the right amount of access required dynamically.

Because all the sandboxing doom and gloom calls ignore that Apple implemented as part of it's security strategy almost EXACTLY what Wil was saying was the right solution. I see a very different article that you do, reading the same text.

Part 1 was a commentary that last November Apple wasn't done and it looked like a hard job. So? The section was completely void of any difficulties for developers, he pretty much only pointed out difficulties for Apple in making entitlements available, I didn't see anything that said developers will be screwed. So no FUD in that section and nothing there to support the FUD crowd. Well it isn't easy for Apple to implement, but I don't agree it is quite as hard as Wil was making it out to be. It also isn't as critical to be 100% effective or go home as he thinks it is. It just needs to be damn effective. And inevitable holes get plugged as they get found. It would be ridiculous for Apple to not do anything with sandboxing just because it's hard to implement. So I'll agree he isn't a sandbox supporter, but the why is important, and the why boils down to hard for Apple -- not difficulty for devs.

Part 2 was red herring for anyone who thinks it says anything about sandboxing. It says nothing about sandboxing, it only says the obvious-to-any-CS-major ~you cannot analyze a program and know with a guarantee that it will never do bad things.~ Becaue that is a version of the Halting Problem, and very true. This is actually a reason for implementing both sandboxing and code signing, specifically because of the Halting Problem. Anyone trying to use Part 2 as ammunition against sandboxing was completely missing the reason he wrote it was to set up his part three -- certificates (non-MAS code signing).

Part 3 literally is what Apple has done for the non-MAS crowd. Specifically because Apple knows 3rd party hardware drivers cannot live with MAS sandbox limits, and also that not all Apps on OS X will be properly sandboxable for the first year or three, or maybe the devs won't have the budget to move into a sandbox before the next big rev. So code signing is an active part of the sandbox security effort even though it lies outside of the sandboxes. It allows users to feel all fuzzy even though they didn't get the same set of security assurances from Apple as sandboxed apps have, because the code signing dev has been stand-up about being in the community as a responsible player.

I don't see how anyone can actually read the full article as contributing to anti-sandbox FUD. I only see that sandbox FUD deployers took a few out of context sentences and wrapped their own words around those isolated sentences to try to make it look like Wil said sandboxes are bad. He said no such thing, at best he said he liked code signing more, and I never saw him say he couldn't work within whatever framework Apple put in front of him.

I agree with all his factual callouts, and only differ on the opinions of how hard it might or might not be to implement in the short term, and that I think it is valuable even if there are some early holes that will need to be found and plugged. I look at iOS and see 4+ years of Darwin based sandbox technology so the OS X sandbox implementation is far from starting from scratch with zero feedback to date. A lot of the basic architectural kinks have already been ironed out from iOS work and the more OS X and iOS converge the more that iOS sandbox experience helps.

Make more sense now?

I'll make this my last post on this.

No your argument doesn't make sense. Developers, from those producing some of the top selling applications in the MAS down to small one-person companies selling low volume apps, have raised numerous issues over those apps which are currently in the MAS which are not compatible with sandboxing - Apple themselves acknowledge such apps exist and some will never be compatible (and they are not "drivers").

My point was, and is, that the article held the promise of discussing these developer concerns. It is unfortunate it did not. I played the devil's advocate, summarizing a few of the concerns I'd read, just to show they were out there.

You've countered "its all FUD" but I'm sorry I've found your argument has been lacking, you've certainly not addressed many of the particulars of the concerns developers have raised. Your jibes about developers not reading documentation brought a smile when some key documentation on the sandbox was only released last week - 2 weeks before the deadline by which developers must implement sandboxing for new/bug fix submissions to the MAS.

I personally don't doubt Apple has a business plan to make lots of money; but how happy existing customers and developers are we'll have to wait and see. A lot of the initial concerns will of course go, humans tend to resist change. But this time there does seem to more underlying the concerns than mere resistance to change. I wish the article had dealt with this - and put it to rest or not. It did not, oh well.

Have a nice day.

In regard to this it is worth noting that Apple is encouraging developers to break applications up into a collection of separate parts each of which has just the static permissions it requires; this should be transparent to the user. To the developer it certainly is not and often requires substantial work. The current system also appears to have significant limitations (as Apple seem to acknowledge). Combine those two and it is not surprising that the developer reaction has been mixed. So the plan is there to limit the permissions at any point in time, but its realization will probably take some time.

Calling the whole thing "capability based" I don't think is right - such systems are both far more powerful and flexible at the same time.

Whether you like or don't like my points are immaterial, they are basic. When what parts of what documentation were available when are immaterial. That they are available for devs to read -- before your series of unfounded, vauge and simplistic complaints were written -- means the information completely contradicting your/(the devs you claim to be speaking of) complaints was already publicly available. Devs complaining before they read the documentation were not in any way making reasonable complaints - they were just whinghing. Devs continuing to complain after -- well gee that's just not productive.

Even the biggest almost legitimate complaint -- Apple could pull the plug on a App any time they want because of the code signing, obviates the fact that EVERY OS designer has that ability if they wish to exercise it. The reason that is only an almost legitimate complaint is because it is a step that is not palatable for Apple (or MS or any other OS vendor) to take due to anti-trust issues unless the throttled code is a verified malicious security problem. Every business interaction requires trust, and every dev has no choice but to trust that Apple won't revoke a certificate unless there is a clearly valid, in the eyes of anti-trust law, reason. Personally I don't see that as taking a lot of trust, it is just a theoretical hyperbole that contributes to the FUD once you look at the business and legal reality of the situation.

Bye, don't let the door hit you on the arse on the way out.

Get this. We as users don't care that there is extra effort on the par of the developer. We want software that doesn't suck, isn't broken and not contributing to security issues on our machine.

As a software industry participant, I mostly see and fight against no end of truly shoddy work in the name of making a schedule. The really sad part of that is that most of the schedule problems are self inflicted by poor or no pre-coding design, poor adherence to any kind of best practices, and and poor understanding of techniques to reduce development risk and code problems.

Interestingly, most of those best practices tend to support an application design that would be sandbox friendly. But tell an entirely too large a cross section of coders put there how to do or design their work and they tell you not to mess with the execution of their programming art. Follow that problem up the all to large cross section of coders that would be better employed as shoe salespersons and we get awful close to a majority of the code writers not helping, and not liking being told how to do things.

The true code craftsmen plus those trying to make the art into an engineering endeavor don't have issues with best practices and design advice that will make their jobs easier. Any software designed in the past couple years that isn't already implementing well separated concerns deserves the fruits of those poor design choices.

For those projects that are too large and established to re-architect with years of work by both good and bad coders none of the above matters because they can chose to code sign if they haven't already. The chance any app in this category made the rest of the MAS packaging requirements is very slim so the sandboxing is a total non-event.

Projects that need low level OS interfaces like hardware drivers and maybe some bleeding edge performance critical software like games are also not prime MAS players. Many games aren't in the MAS simply because someone made incompatible installation choices, drivers aren't intended for the MAS either. But they both get code signing to get their equivalent coverage in the eyes of the consumer. Even the gaming issue is debatable when guys like Carmack are taking about MAS deployed titles in their future. If Carmak doesn't think MAS compatible design and deployment packaging will ruin his elevated personal requirements for his software, I hardly think there is a valid pervasive MAS driven problem in the performance area.

So where are these "real" problems I read that are alluded to, and complained about, but not really in the sunlight?

From Apple:

Sandboxing Deadline Extended to June 1
Feb 21, 2012

We have extended the deadline for sandboxing your apps on the Mac App Store from March 1st to June 1st to provide you with enough time to take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3. Get more details about sandboxing your app and find answers to FAQs.

So developers have another 3 months. Sandboxing just wasn't ready (10.7.3 & Xcode 4.3 were only just released) confirming the concerns of many developers. This is the second postponement.

Or Apple listened to the cacophony of whinghing and decided to slide the deadline to shut them up, having already planned the maneuver knowing what was about to transpire.

Nothing dramatic is going to change from now to then, and developers have had access to 10.7.3 builds since November. The only thing that really changed in the whole situation is that devs finally woke up to the fact that the sandbox deadlines were really going to happen, not just be empty warnings. And because they were in denial before they needed more time to catch up now.

Now, REALLY, think about it. What happens sometime relatively close after that 1 July deadline? 10.8! Now don't you think Apple's REAL intention was a MAS store fully operational on Gatekeeper aware apps BEFORE 10.8 shipped? A three month slide just lets Apple make the magnanimous gesture while still maintaining the timeline they really want.

It doesn't take a rocket scientist to see it all fit together. And it was there all along for any dev who cared to think about it. With the initial cues beginning several years ago (all the way back to 2007) with references to code signing.

That's exactly how I see it but I certainly couldn't have worded it as well as you did.

Don't join the misinformation here, read Apple's announcement. Xcode 4.3 has just been released and contains "new APIs" - that is APIs for the sandbox.

Could developers have adopted those new APIs in two weeks (design, test, test again) and ship high quality software? In general, no.

Do you have any idea how important those new APIs are? Well it seems they're important enough to provide time to use them. If it only effects a small percentage of the apps in the Store why postpone?

If you believe, as some developers appear to, that the "deadlines" have just been the stick to get the sandbox tested; and that the sandbox is being released according to a great plan in sections each with a "deadline" is irrelevant (frankly I don't think Apple would use a stick like that, it couldn't be called good for developer relations, but maybe I have too high an opinion of Apple's morals). Even if it is true the developers' concerns that the sandbox was not complete and the announced deadline untenable would still be valid. And as developers were asked by Apple to test the thing, expressing concerns was the right thing to do - it is not whinging, it is doing the job.

The App Sandbox APIs were added in XCode 4.1. The toolsets have been tweaked since then, which I'm sure could include some evolving API tweaks, but the primary functionality has been around since last July or so.

Devs simulating ostriches don't impress me. Making excuses for them even less so.

This has been pushed at devs for over two years now, they just thought they won with the avoidance of sandboxing requirements when the MAS launched and the original slip. I think complacency set in, now Apple is surprising them and Cook isn't a pushover. Anyone who though it was all Steve that decided how to dispense tough love to the community is a bit out of sorts about now.

I first posted here to comment on my disappointment at the lack of detail in the associated article. I've long since regretted it - though I did enjoy playing devil's advocate for a short while at least - as it triggered an avalanche of misinformation and vile directed at developers - the folks who make the apps we all use.

I posted the latest announcement from Apple to provide some balance, after all who could disagree with Apple's own take?

Yes I'm naive

For those of you who turn up here looking for information a little fact on Apple's announcement, rather than unfounded opinion: The "new APIs" Apple refer to add new core functionality to the sandbox, the absence of which had been raised by many as a significant block, and as I understand it Apple themselves had stated they were investigating. This was available and documented for the first time in recent days. If you're a programmer you can download Xcode 4.3 for free from the MAS and read about it yourself.

Apple are not stupid and knew that 2 weeks would not be sufficient for their hard-working developers to adopt these developments. Read what Apple wrote, not uninformed interpretations of it. Apple's public statement. emphasis added:


Apologies for having triggered a tirade.

I wouldn't call my reactions a tirade. But my reactions have been strong in rejecting the notions that developers have been at some magical disadvantage that entitles them to some measure of slack.** Your original implication, and repeated confirmation, was that it was not possible to do sandboxing before XCode 4.3, which is patently incorrect. Whether by general lack of knowledge or by your misinterpretation of what the phrase "new sandboxing entitlements available" meant doesn't matter.

APIs and tools are ALWAYS evolving, just like hardware is always evolving. If a buyer forever waited for the most recent projected capabilities whenever a new hardware capability was announced or rumored, they would never buy any hardware. The original sandbox entitlement choices and tools existed for a long time and were released for open development last July. Code signing tools and developer conference talk of the coming requirements has been building since 2007. The fact new wrinkles are added at any particular time does not make a world where it is sensible to have repeatedly ignored the originally available tools and guidance because evolutionary improvements might come out later.


**My soapbox about the overall poor state of affairs in the software industry and many developers attitudes are quite independently derived from this sandboxing discussion. There's no misinformation in my soapbox, just more years of experience, research, development, negotiation and leadership challenges then you can shake a stick at.

Industry and academic development/engineering research quite adequately identifies the failings and the magic 100K LOC that they start reliably killing projects at. And the research also describes correlations with why the mere 10% of those projects over 100K LOC don't seem to fail regularly. Those correlations tend to revolve around developer/coder willingness to subject artful independence to a measure of engineering design and process standardization. Anyone around long enough understands it at a gut level and doesn't need to read the all the articles and papers to know that.

[QUOTE=Hiro;2053235Your original implication, and repeated confirmation, was that it was not possible to do sandboxing before XCode 4.3, which is patently incorrect.[/QUOTE]

The first mention of Xcode 4.3 in this thread was in Apple's statement, and hence it is impossible there was any original implication that some apps could not be sandbox prior to 4.3.

You do write such utter nonsense.

Indeed there as never been any suggestion that it was not possible to sandbox some subset apps, no developers claim that. The whole question is around how large that subset is, and Apple state it is a subset.

The subset was sufficiently enlarged by 4.3 that Apple decided to extended the deadline to allow adoption - according to Apple.

To anybody else who reads this thread: whatever the comeback expect an absence of response.

How mature and trite. Expect an absence of response! So is it when you get exposed for not having done your background preparation you appeal to the other readers to ignore the response because you say it won't have "response" (whatever that's supposed to mean.) Well it just happens to be your un-lucky day that the cold hard facts just continue to rain down and don't seem to be changing at all.

I can't follow your first sentence at all. "The first mention of Xcode 4.3 in this thread was in Apple's statement" ? what are you getting at? The statement is completely baffling.

If you are trying to say Apple's first mention of sandboxing APIs was in 4.3 you haven't paid any attention to the actual developer documentation. I don't base my opinions only on the read me file. I actually look up the What's New in the online dev docs. So if your broken statement just got squashed because you don't actually do your homework completely that's your problem. Maybe if you had read the 4.1 What's New page last July you wouldn't be in the middle of this misconception now.

As for enlarging the subset of available entitlements in XCode 4.3, that's not news from out of the blue, that's evolution of an existing published capability. As I pointed out earlier, the topic has been evolving since 2007. Dude none of these changes were out of thin air. Moreso, that fails to acknowledge that devs get access to beta builds to test and explore, to further remove the possible surprise factor. All of which conspire to seriously weaken a argument that changes in XCode 4.3 were so new and critical that entitlements and applications implementing sandboxing were not possible before that.

But you keep ignoring that.

Interesting and timely. . .

OK, so my English baffled you, so I'll just correct that.


Response:


Because there never was any such argument... \

The End.

I guess I'll agree that's the end because you just pretty much removed the content from your arguments.

If sandboxing minus the XCode 4.3 subset of capabilities didn't make it impossible, what was there to get so defensive about in the first place?