Mac App Store Sandboxing Requirement Pushed to March as Uncertainty Looms

[Apple Big Mac]

This model isn't to prevent malicious Mac App store apps. It's to prevent apps from being exploited/hacked to do bad things.

I understand that rationale, but how often do such targeted attacks (malware in conjunction with exploits in third party apps) actually crop in the wild? I know that third party system components like Flash and Acrobat have been exploited, but do Mac app store apps really pose much of a danger in that regard? It seems like a fix for a very remote threat, a cure that appears more problematic than the "disease" it's supposed to remedy. It's quite natural to assume, based on recent Apple moves to consolidate control, that the real disease being targeted is the independent developer and companies that are resisting moving to the restricted app store environment.

On another note, I want to thank you, arn, for the years of excellent Apple coverage on your site. I've been an avid reader of Mac Rumors likely since you started the site, and when the rumor cycle heats up, I often visit more than once a day. I also really enjoy the fact that you interact with your user base by contributing directly to threads on your forums.

 

[DESNOS]

New sandboxing idea:

Allow sandboxed apps to operate as normal, but allow the developer to place as many restrictions on the app as he wishes for the sake of security, so long as it doesn't affect the app's functionality. I think that's ideal. It would really be the best of both worlds. The benefit of this is that over time Apple could add all sorts of "optional" restrictions that could increase this security even further if they should chose to use them. I think this sort of system would be something that Apple could reasonably request developers to use.

Another idea is that at compile time, it could be determined what resources the app needs to run, and only allow those and nothing else. That would actually work quite nicely, although it would need to be rather sophisticated, so that may be more trouble than it's worth.

 

[degsyuk]

Not secure at all

Sandboxing some applications will not improve the security of the platform as the file system would still be vulnerable to attack from any compromised non-sandboxed application. It's a bit like leaving your house with the doors locked but all the windows wide open. I can only guess at their "end-game" but it looks as like they are introducing a model styled on the games console where the manufacturer determines what applications are available and how they can be used.

Apple have made and reversed similar decisions before (what is and isn't allowed in the App Store) and so I expect this one to be watered down if not abandoned altogether. Despite appearances this will inconvenience end users far more than developers. Developers are accustomed to regularly buying new hardware and learning new programming interfaces and languages. If developing for the Mac becomes too difficult, they will simply move to another platform. Should that happen end users will have even less software to choose from. I know it's possible to run Windows software on the Mac, I've seen it done and it makes me smile as i can't help thinking that those that do it have missed the point.

 

[rudigern]

I might have miss understood this but preventing all apps from doing anything from, say, changing the file system wasn't their intention.

When you signed your App for distribution in the App store you would select which entitlements you would need. The entitlements were either allowed or disallowed by Apple as part of the App submission process.

If your "Space Invaders" game required file access outside it's sandbox it would be rejected but if Transmit required access it would be allowed.

It was a way to prevent Apps that didn't think about security (like games) to have access to the same level of authentication as Apps that did, like Transmit.

Happy to be told otherwise but this was my understanding of it as it was presented to me at WWDC.

 

[ksgant]

I'll hold off judgment for a while. If they just restrict this to the app-store applications only, then that's okay. If they totally lock down the OS, then I'm gone...and this is from someone who's been a loyal Apple user since 1979 (give or take a few side-trips to PC-land).

The thing is, I could easily move my entire life over to Windows at the drop of a hat. All my data. All my applications...everything. It would take a few days I'm sure to orient myself, but I could do it and I will if they keep squeezing closed OS X.

 

[CodeBreaker]

Why? Isn't it safe enough?

a normal application run by a user has the ability to delete every single file owned by that user.

And they will allow such a thing in the App Store, right?

 

[Don Kosak]

Okay --

I have a certain feeling of security when I install an App on my iOS devices. I know there is a very limited amount of damage they can do, as they're heavily sandboxed. If I don't like the App, I can remove it, and know that nothing is left "tucked away" inside my system slowing it down or interacting with my other software.

On the Mac, when I download an App, I still feel pretty uncomfortable. In fact, on my main iMac, I have very little software other than iLife, iWorks, (MS Office 2011 for client work), and Xcode. I would buy more software if it was sandboxed.

As far as cross-app communications and such, Apple needs to update AppleScript to support public API's for scripting sandboxed Apps. The user can decide to grant "Evernote" access their calendar or browser if they want.

----------

Why? Isn't it safe enough?
And they will allow such a thing in the App Store, right?

Have you heard of MS Word viruses? PDF viruses? You open a file that contains a script that exploits a bug. If Word or Acrobat has full access to your entire system, including your files, keyboard driver, camera, mic, etc -- you're hosed.

It's not that the Word or Acrobat are malicious -- they are not. But as they have full system access, they become entry vectors for malware. Sandboxing fixes that.

 

[subsonix]

I might have miss understood this but preventing all apps from doing anything from, say, changing the file system wasn't their intention.

Exactly.

It really is nothing more than a per application permission model added to the existing per user permission model already in place in OS X and all other Unix systems. Applications such as chrome and virtual box already runs sandboxed, it's the right decision to add this at the OS level with public api's.

 

[hchung]

Perhaps Apple should educate consumers about sandboxing and then describe all apps as "sandboxed" or "not sandboxed". Those who want the safety and are willing to accept limitations can feel secure with Apple's guidance. Those willing to take a measured risk should do their homework and allow greater developer freedom.

Basically, they want all apps on the App Store to be sandboxed. And then apps acquired from outside of the App Store can be sandboxed or not sandboxed as the developer desires.

It's not like the Mac will only run App Store software.

Yeah, this inconveniences people who want to get all their apps from the App Store. On the other hand, it becomes a clear choice for those who just simply arn't technical enough to google for a solution to a tech problem.

So those who are non techie have a safe place to get apps, those who know more can just install them the way we've been doing for the last 30 years: from wherever we find it.

----------

You can already see the affect on iOS that sand boxing has, severely restricting applications.. no Black List calling apps, no profile apps ( i.e., change ring tone, Bluetooth on off at given times or events ), for example.

Applications that other platforms may take fore-granted just aren't available, and very useful ones too... except on Cyndia.

Yes, we also don't have that impressively sneaky app that spies on your voice calls, identifies if you're speaking 16 numbers in a row and then sends the voice clip to a foreign server. (google for Soundminer)

There's upsides and downsides to security.
More freedom == less security.
More security == less freedom.
They're pretty much opposites.

----------

I don't see what Apple is so paranoid about when it comes to Mac App Store apps. As has been pointed out, Apple already approves Mac App Store submissions, so why restrict them even further, thereby making the App Store distribution model even less attractive to real developers?

The reason that they're paranoid is pretty much because as it is right now, the Mac App Store and iOS App Stores are very very different.

On iOS, yeah, it's pretty locked down.

On the Mac App Store, as the article suggests, there's barely any restrictions. And some apps depend private APIs, access everywhere, and/or all sorts of potentially insecure stuff, so they're approved despite these exceptions. They can audit the app submissions. But given there's so much more leeway given to an Mac App Store app currently, they aren't able to provide the same sense of safety.

For the most part, people think that apps on the Mac App Store are as safe as the apps on the iOS App Store because they trust the iOS App Store and assume that because the Mac App Store is newer, it's got the same kind of assurances. They are not the same. A Mac App Store app is less safe than an iOS App Store app, despite both being reviewed.

----------

New sandboxing idea:
Allow sandboxed apps to operate as normal, but allow the developer to place as many restrictions on the app as he wishes for the sake of security, so long as it doesn't affect the app's functionality. I think that's ideal. It would really be the best of both worlds. The benefit of this is that over time Apple could add all sorts of "optional" restrictions that could increase this security even further if they should chose to use them. I think this sort of system would be something that Apple could reasonably request developers to use.

That doesn't work for two reasons:
1) A developer can't list the ways their app can be exploited because if they could, they could fix it.
2) Additionally, if additional restrictions were added later, there's no guarantee it wouldn't break the app.

Sandboxing is a whitelist as opposed to a blacklist because it's easier to list "this is what I need" than to list "these things I don't need". Because the list of "things you don't need" is basically infinite.

 

[Jerome Morrow]

I might have miss understood this but preventing all apps from doing anything from, say, changing the file system wasn't their intention.

When you signed your App for distribution in the App store you would select which entitlements you would need. The entitlements were either allowed or disallowed by Apple as part of the App submission process.

If your "Space Invaders" game required file access outside it's sandbox it would be rejected but if Transmit required access it would be allowed.

It was a way to prevent Apps that didn't think about security (like games) to have access to the same level of authentication as Apps that did, like Transmit.

Happy to be told otherwise but this was my understanding of it as it was presented to me at WWDC.

See local morons always blow things out of proportions with their doomsday scenarios.

 

[heisetax]

No Mac App Store Please

I don't like the restrictions of the iTunes App Store. I believe that there needs to be a direct channel between the software developer & the end user. Between my iPod Touch & iPad I have close to 500 apps. Of these only about 5 are purchased apps. That means that only 1% are making any money from me. Not a very good business model. Even if I didn't have all of those free apps I still would not purchase any other apps.

When it comes to the Mac App Store the only program that I have purchased has been the new Mac OS 10.7 Lion. And unlike other App Store updates the updates come straight from Apple as they really know that there needs to be that direct connection between the software developer & the end user. I haven't even though of looking at the Mac App Store for Mac software. I still get all of my new Mac software & Mac software updates wither directly from the developer or from non-Apple 3rd party sources that I have used for years.

I know that the vocal minority will use the Mac App Store, but those that really get into their software will not willingly give up the required control. They do not want their software dumbed down. They want the new greater & better software. The best that the software developer can do with the current hardware. They & me at least does not want to purchase the new & not as good as the previous model software that has been dumbed down. The fact that this is what will happen has been shown by the most major piece of software only available on the Mac App Store, Mac OS 10.7 Lion. To me it is really a dumbed down version of what should have been. This is the first time I've installed an update & wish I hadn't. Even after turning off all of the new dumbed down items I find some changes to be very bad. The only reason I do not use any of my copies of Mac OS 10.6.8 is because I like my new setup of Windows under Version 7 of Parallels. A none Mac App Store update.

I suppose those that believe that Apple can do no wrong will keep the Mac App Store running. It just won't be me. I've purchased only Macs since my first one in 1984. I am not a convert from MS-DOS or Windows to the Mac. I went straight from my CP/M HeathKit to the 1st gen Mac. My only native Windows computers are my Intel Macs.

 

[hchung]

Sandboxing some applications will not improve the security of the platform as the file system would still be vulnerable to attack from any compromised non-sandboxed application.

Sandboxing will not protect from non-sandboxed apps. This is indeed correct.
But think about it this way, which is the better option in terms of security?

1) All apps can do whatever because there's no sandboxing.
2) Some apps are sandboxed. Some apps are not sandboxed.

You're still vulnerable if you get exploited in a non-sandboxed app. But for all the apps you have which are sandboxed, they arn't an exploit target anymore.

For every app you have which isn't hurt by sandboxing, you have one less app to worry about.

----------

Why? Isn't it safe enough?

a normal application run by a user has the ability to delete every single file owned by that user.

And they will allow such a thing in the App Store, right?

In the Mac App Store right now, just like in any app you download, there is no way without sandboxing to guarantee that an app won't delete every file in your home directory.

Why?

Because despite scanning and auditing the app, it's impossible to know if any app will try such a thing. This is something that is unlikely to change.

You can audit and app and be reasonably sure if you see no obvious "delete file" code, but that is no where near a guarantee.

 

[arn]

If your "Space Invaders" game required file access outside it's sandbox it would be rejected but if Transmit required access it would be allowed.

It was a way to prevent Apps that didn't think about security (like games) to have access to the same level of authentication as Apps that did, like Transmit.

Happy to be told otherwise but this was my understanding of it as it was presented to me at WWDC.

The issue here is that the level of file access that Transmit wants/requires is not among the list of permissions you can ask for.

From Transmit developer:
http://twitter.com/#!/Cabel/status/131918123673731072

@arnoldkim They want all file interaction to go through the "Open" panel. Directly displaying/interacting with disk contents is verboten.

 

[hchung]

I don't like the restrictions of the iTunes App Store. I believe that there needs to be a direct channel between the software developer & the end user. Between my iPod Touch & iPad I have close to 500 apps. Of these only about 5 are purchased apps. That means that only 1% are making any money from me. Not a very good business model. Even if I didn't have all of those free apps I still would not purchase any other apps.

When it comes to the Mac App Store the only program that I have purchased has been the new Mac OS 10.7 Lion. And unlike other App Store updates the updates come straight from Apple as they really know that there needs to be that direct connection between the software developer & the end user. I haven't even though of looking at the Mac App Store for Mac software. I still get all of my new Mac software & Mac software updates wither directly from the developer or from non-Apple 3rd party sources that I have used for years.

I know that the vocal minority will use the Mac App Store, but those that really get into their software will not willingly give up the required control. They do not want their software dumbed down. They want the new greater & better software. The best that the software developer can do with the current hardware. They & me at least does not want to purchase the new & not as good as the previous model software that has been dumbed down. The fact that this is what will happen has been shown by the most major piece of software only available on the Mac App Store, Mac OS 10.7 Lion. To me it is really a dumbed down version of what should have been.

Lion is dumbed down not because of the App Store. Lion is dumbed down because Bertrand left, and now somebody else (I think, less competent) is in charge.

So why not go back to Snow Leopard? Parallels 7 will run on 10.6, right? If you just backup your Parallels VM and restore it, you'll keep your Windows VM as it is.

(I have Lion on a work desktop. I hate it. I continue to run 10.6 on my laptop.)

 

[Jerome Morrow]

The issue here is that the level of file access that Transmit wants/requires is not among the list of permissions you can ask for.

From Transmit developer:
http://twitter.com/#!/Cabel/status/131918123673731072

Like anything else it will be worked out.

----------

Lion is dumbed down not because of the App Store. Lion is dumbed down because Bertrand left, and now somebody else (I think, less competent) is in charge.

So why not go back to Snow Leopard? Parallels 7 will run on 10.6, right? If you just backup your Parallels VM and restore it, you'll keep your Windows VM as it is.

(I have Lion on a work desktop. I hate it. I continue to run 10.6 on my laptop.)

If you live in Neverland.

 

[Stella]

For now.. but Apple would like the AppStore to become the defacto method of Apple software distribution, in the future it may very well not matter that 'is it possible' to get your applications from outside the MAC.. because that would be the only source for the vast amount of software, especially from smaller developer shops ( like the ones highlighted in the story commentary ).

It's not like the Mac will only run App Store software.
Yes, we also don't have that impressively sneaky app that spies on your voice calls, identifies if you're speaking 16 numbers in a row and then sends the voice clip to a foreign server. (google for Soundminer)
There's upsides and downsides to security.
More freedom == less security.
More security == less freedom.
They're pretty much opposites.

There has been criticism that Android applications are poorly vetted in various Android AppStores. So the fact the rogue applications may see the light of day on Android phones, doesn't necessarily mean the same for iOS - which are examined more closely.

Here's one example:
http://www.csoonline.com/article/686128/android-app-vetting-is-still-weak-says-security-developer

There has to be a balance between developer freedom and security. In the case of iOS, Apple have taken the paranoid approach - and security has gone TOO far. Apple will take the paranoid approach for MAC too, at the cost of innovation - and we've seen the beginnings of this on the MAC already - applications that aren't allowed on the MAC - such as Transmit ( a fine application, yet a run-of-the-mill multi-protocol file transfer application ). 1Password had to lose quite a bit of functionality to be allowed on.

Personally, I'd like the option for iOS that I could freely 'side load' an iOS application for more developer freedom at the slightly elevated risk that I'd install some rogue application ( of course it won't happen because Apple won't get its 30% cut for paid software )

 

[Manderby]

You know, I was struggling to write something here because, actually, I don't really understood why I think this is simply wrong.

What happends here is that Apple starts flat out disputing the functionality of Mac OS X. Shoveling the responsibility over to developers. That's what happends.

This means, that they accept the current systems functionality and flaws without greatly change or improve any of it anymore. It's not astonishing as there is really not much more to do in a system. It's a dog chasing its own tail. It works good enough, I bet there are not many engineers actually working on the core system anymore. Why should they put much effort into it?

But this also means that they will not gain much money out of it, which is what happened in the last few years. Finally, they will drop the responsibility all together and just have some custom software (Sandbox) running on top of it. I expect Mac OS X to be free and open in three years.

And thinking about that... this might actually not be that bad after all.

But nonetheless, having more responsibility sucks.

 

[mabaker]

This issue needs more exposure as it's extremely important for a healthy Mac app environment. MANY of the apps we all love will not be possible if Apple were to force sandboxing on ALL apps installed on Lion.

 

[vitzr]

1) There's no debate that sandboxing is more secure.

2) The question is how much you really care about it at the expense of certain types of applications.

arn

1a) I concur, and must admit I wrote my post in haste after reading some of the initial responses.

2a) It is this point that you have so accurately described that is the sore spot for me, since I am well aware of the consequences. Many of which are of more significance than many here realize.

That said if it must be (sandboxing) I do agree that it's wise of Apple to push the date back so as to allow those involved ample time to make the needed adjustments.

 

[gnasher729]

Whats next ?

Apps no longer utilize the file system ?

Can we just make the iMac a big iPad now ?.....That's really what we all want ...Right ?

Clueless rant. A sandboxed app cannot read or write or delete or modify any files in any places that it wants. A sandboxed app _can_ open the usual file dialog, lets the user select a file, and do anything with that file that it wants.

In addition, a _malicious_ app that is sandboxed _cannot_ read, write, delete or modify any files in any places that it wants, only files that the user allows it to see, so this adds security if a malicious app made it on the app store somehow. And any app that fell victim to some outside attack _cannot_ read, write, delete or modify any files in any places that the attacker wants.

This model isn't to prevent malicious Mac App store apps. It's to prevent apps from being exploited/hacked to do bad things.

It also helps preventing malicious apps in the store. If an application asks for the capability of reading my address book, and for the capability of sending e-mails, and there is no reason why the app should have these capabilities to function properly, then it can be rejected.

I understand that rationale, but how often do such targeted attacks (malware in conjunction with exploits in third party apps) actually crop in the wild? I know that third party system components like Flash and Acrobat have been exploited, but do Mac app store apps really pose much of a danger in that regard? It seems like a fix for a very remote threat, a cure that appears more problematic than the "disease" it's supposed to remedy. It's quite natural to assume, based on recent Apple moves to consolidate control, that the real disease being targeted is the independent developer and companies that are resisting moving to the restricted app store environment.

Malware is bad now, and it is going to get worse. What Apple does here, and which is what anyone involved in security would advice them to do, is called "defense in depth". Apple protects you at their end, by adding application signing (so if you download an application that says it was created by xyz company, then you can be sure it was created by xyz company and hasn't been tampered with), and by making it hard for an attacker to make an app do what they want it to do instead of just crashing. Making it hard is not making it impossible, especially if an app has logic bugs. Sandboxing does the same on the application side, making it _impossible_ for the app to ever do things that the developer didn't want it to do, even when attacked successfully, and allowing the developer to extract potentially dangerous into isolated pieces of code that are easier to make safe against attack.

I find this ridiculous. The people that would get the maleware on their machine that exploits an app are the same people that would get maleware on their machine that compromises their system anyways.

It's malware, not maleware. Or are you running only femaleware on your Mac?
This is not about apps being attacked by malware on your Mac. It is about attacks against your apps from the outside.

 

[haravikk]

Surely this is overreaction? Just because apps have to start using the sandboxing features, doesn't mean they have to give up features surely? The expectation is that the apps declare the minimum privileges that they require in order to function and, where possible, restrict potentially harmful privileges into smaller, isolated functions.

So for Transmit, all it needs to do is isolate the part of the program that processes arbitrary files (i.e - might potentially execute malicious code), and restrict its access to the rest of the app's features, which should be unaffected.

 

[vitzr]

Everyone should just stop using the Mac App store. Apple doesn't need any more control over OUR computers. They also don't need to take money away from the developers that supported their platform.

I could not agree more.

It's why I stopped upgrading at 10.6.5.

The next rev, 10.6.6 included the Mac App Store.

 

[TiggsPanther]

A sandboxed app _can_ open the usual file dialog, lets the user select a file, and do anything with that file that it wants.

Oh. Is this why a video screengrabbing app I bought now constantly asks where to save its thumbnails - rather than just dropping them back in the same folder the video files are?

It never used to open a file dialigue to save the resulting thumbnails. It would just drop them next to the source videos.

 

[baryon]

I really hope this doesn't compromise features. Since App Store apps are not likely to be malicious anyway, why limit them? They've been checked by Apple, they're entirely safe. Sandboxing only makes sense if the App is dodgy and thus NOT from the App Store.

 

[FourCandles]

There's no debate that sandboxing is more secure. It is.

The question is how much you really care about it at the expense of certain types of applications.

arn

^^ This is the key.

...
So, if GeekTool has to be pulled or whatnot, I can still get it, for free, at their website.

Of course. The issue is, for how long? Or, to put it another way, until which release of OS X?

Apple will not put OS X "in jail" as long as Microsoft doesn't sell Office in it.

Sarcasm aside, an interesting point and we could turn this around and just say that when the moment comes when Apple judge that all the financially important developers and apps are on board the MAS (e.g. MS Office, Adobe CS, whatever), then they can pull up the drawbridge and make the Mac a closed system like iOS.

...
Apple will take the paranoid approach for MAC too, at the cost of innovation - and we've seen the beginnings of this on the MAC already - applications that aren't allowed on the MAC - such as Transmit ( a fine application, yet a run-of-the-mill multi-protocol file transfer application ).
...

Whilst I fear that you're correct in your prediction, I can't see how having an FTP application for a machine that is supposedly still the #1 choice for designers, artists and web developers could be thought of as innovative. I would have said it's essential.