Mac App Store Sandboxing Requirement Pushed to March as Uncertainty Looms

[arn]

Are the Apps mentioned Cover Sutra, Fantastical, Transmit, and TextExpander malicious? Is that why they won't or don't support sandboxing? I'm not sure I understand this correctly.

No, those apps do things that aren't allowed in the sandbox. Such as talking to other apps, or accessing the file system.

arn

 

[shadowlawless]

Apple introducing a new standard of coding, without trying to control everything.

My First post, I guess I'm the newcomer. I've only been around computers for the last 50 years, mainframes. This was mostly US Gov't computers, then US Military. In 1980, bought my first Apple, an Apple //c. As times changed, I moved to this new thing called, "The Internet", We always knew it as the "ARPANET". One of my instructors was one of the pioneers, she had one life lesson, she would always stress balance. Let's leave the virtual world and come into the tangible concrete world. In a ball and socket joint, there is a tiny, tiny gap between the two. Without that gap, the two will freeze solid and not move at all. Apple cannot control this whole ecosystem, if they try, the whole ecosystem will freeze solid. Sandboxing has a place under the hood and only under the hood. The last group are the end users, if Apple Policies frustrate them enough, Apple and and Apple shareholders will ultimately lose everything. This will be Apple's choice, they've earned it. They should be thinking about the end users first and not just themselves.

The thing is, what apple is trying to do is less like micromanaging or controlling, and more like setting rules and regulations to ensure quality of the apps. When a product is made, before it is released it usually has to pass certain tests to ensure it is of high quality this is no different.

What apple wants is for each "process" within an "App" to only have access the exact resource it requires. All it means is that each "process" will not have access to everything that the "application" has access to. this way all processes are harder to exploit, (which is how hackers install virus' ect) also allowing each process to be shared out between cores on a computer increasing efficiency and speed of the app running. it also means if any of these "processes" crash, the "App" can keep running and the "processes" can be restarted, reducing the probability of crashes.

for example

"A process that's decoding video probably doesn't need any access to the file system, the network, the built-in camera and microphone, and so on. It just needs to accept a stream of bytes from its parent process (which, in turn, probably used Powerbox to gain the ability to read those bytes from disk in the first place) and return a stream of decoded bytes. Beyond this simple connection to its parent, the decoder can be completely walled off from the rest of the system. Now, if an exploit is found in a video codec, a malicious hacker will find himself in control of a process with so few privileges that there is little harm it can do to the system or the user's data."

http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/

As for accessing the rest of the system

"Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action".

http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/

it just means that the app will require the "USER" to request access then an entirely different sandboxed process (Powerbox) will access other file systems for the app. which makes it even harder for hackers to exploit apps to install virus' ect. only downside is that developers will have to work a lot harder, which is to be expected if the developer wants a more secure, more efficient and all in all better App

what apple is trying to do is eradicate sloppy coding and i think its a great idea, and will set a new standard for developing in the industry.

 

[kps]

Why does Apple development always make crappy choices. i.e the way LIon saves... balls!

Because Apple Computer Inc. has different priorities now.

 

[subsonix]

Part of the problem here is that this is a developer problem now discussed by end users, hence the confusion.

 

[kps]

Part of the problem here is that this is a developer problem now discussed by end users, hence the confusion.

No, it is not just a developer problem.

Consider, for instance, these examples of sandbox permissions:

• Read/write access to the user’s Music folder
• Read/write access to the user’s Pictures folder

Now if someone wants to store music and pictures in some other way — for instance, grouped with related items under per-project folders, or on an external or networked drive — any Apple Approved™ software will be hampered or useless at dealing with them. And since developers have incentives to get Apple Approval™, it is less likely that such a user will be able to find software for OS X that suits their needs. And that is just another nail in the coffin for any serious use of OS X.

 

[subsonix]

No, it is not just a developer problem.

Consider, for instance, these examples of sandbox permissions:


Now if someone wants to store music and pictures in some other way — for instance, grouped with related items under per-project folders, or on an external or networked drive — any Apple Approved™ software will be hampered or useless at dealing with them. And since developers have incentives to get Apple Approval™, it is less likely that such a user will be able to find software for OS X that suits their needs. And that is just another nail in the coffin for any serious use of OS X.

You can store files in other user defined locations with the use of a file dialog box. It's a developer problem, since much of this relates to changes that needs to be done to the application, regarding separation of functionality with XPC services, (which is an abstraction to simplify IPC communication). It's also a developer problem since most of the documentation, like the WWDC sessions on sandboxing requires a high degree of domain knowledge, which most end users don't have.

 

[kps]

You can store files in other user defined locations with the use of a file dialog box.

That's why I said “hampered”. Do you think I want to spend all my time navigating dialog boxes? No thanks. Repetition is for computers.

 

[subsonix]

That's why I said “hampered”. Do you think I want to spend all my time navigating dialog boxes? No thanks. Repetition is for computers.

Are you sure this is how it works, and not like it works currently, ie you chose destination folder once, have you read the documentation and so on.

 

[KnightWRX]

The thing is, what apple is trying to do is less like micromanaging or controlling, and more like setting rules and regulations to ensure quality of the apps.

what apple is trying to do is eradicate sloppy coding and i think its a great idea, and will set a new standard for developing in the industry.

Sandboxing is quite the contrary. It encourages developers to be sloppy, because "hey, we're sandboxed anyway, nothing bad can happen right ?".

Not to mention it dumbs down the applications because they can't use things like IPC, hardware interfaces and other OS functions to communicate with the outside world outside of the subset provided by Apple.

No really, if OS X ever forces this model of sand boxing, it's the end of it for me.

----------

You can store files in other user defined locations with the use of a file dialog box.

Yeah, sometimes it's fun having the app do everything automatically, without the user having to navigate in a file dialog box. Autodiscovery of media is a "nice to have". With Apple's sandbox, it's an "impossible to have".

 

[hchung]

Apple's not interested in giving people options. Do you really believe that? Mark my words - in a few years time MAS is the only Apple sanctioned way to install proper apps on your Mac.

Mark my words- in 8 years, you'll still be proven wrong. (Specifically: I expect that the Mac will never be restricted to only the Mac App Store.)

 

[Bernard SG]

Mark my words- in 8 years, you'll still be proven wrong. (Specifically: I expect that the Mac will never be restricted to only the Mac App Store.)

I totally agree. I just can't see Apple kissing UNIX certification bye-bye, or the availability of big names products like Microsoft Office or Adobe CS.

 

[Khadgar]

I think we're more likely to see future OSX features limited to App Store apps. That way it won't seem like they're taking anything away.

That could be nearly as bad as taking away features that already exist unless it's for things that require Apple's tight grip... like... iCloud APIs.

Nothing is impossible, but when you look at the technicalities and the implications, the notion that Apple would close the Mac in a iOS way sounds like pure fantasy.

I agree it sounds like a pure fantasy, but like you say nothing's impossible.

I think it's best to see what will happen when March arrives. All these apps, if incapable of following Apple's guidelines, will just simply remove themselves from the store. As I understand it, though, things like FTP clients could be okay. Just because apps are sandboxed don't mean YOU can't obtain access to things outside the sandbox. The key word here is YOU. Apple's developed mechanisms around it. For instance, if you have a sandboxed application open and it doesn't have access to the desktop, but you drag a file from the desktop to it the app will still open it if it can read the file. Why? Because YOU told it to open it. Sandboxes, as Apple has developed them, exist to prevent arbitrary access to different parts of the filesystem, not to prevent you from accessing different parts of the filesystem. FTP clients, like Transmit, never need arbitrary access to anywhere in the filesystem for writing. You tell it when and where to write files. Now, all of this is just speculation based upon my understanding of how this all is designed to work.

The question is what will happen to Apple Events. Sending Apple Events is a temporary exception. I personally think (and therefore hope) that it's because Apple doesn't have an entirely secure method in their eyes for doing that and that the temporary entitlement is just that... temporary until Apple replaces sending the events with something else. I couldn't see them doing away with Apple Events, and evidence shows that they don't really plan on removing it because if they were they'd just prohibit sending events to itself, receiving events, and responding to any event it receives. Then again, who knows what Apple's really thinking anymore.

 

[dethmaShine]

This what some of us have been saying for a while now. Lock it all down. Malware becomes more or less a non-issue. Not that it's a real issue with OS X to begin with. Smart move.



Quite possible that Apple will redesign this implementation in the next iteration of OS X.

Why don't you just shut up?

EDIT: Someone needs to innovate a cyber punch; but yes, without the ****ing sandbox.

On a very similar note, is apple going to limit access to the terminal? I love OS X. It is the best operating system for almost anyone except for hard core gamers. The underlying UNIX is a blessing and I don't want Apple to take it away even though 1% of OS X users use it.

OS X is for the pros. Don't dumb it down for **** sake. iOS needed it. The use case was different as compared to OS X. Please Apple don't **** up. I'd still got to buy a mac as Windows suck but please care about all of us.

ffs

 

[MacRohde]

I totally agree. I just can't see Apple kissing UNIX certification bye-bye, or the availability of big names products like Microsoft Office or Adobe CS.

I really hope you guys are right and I am wrong.

 

[dethmaShine]

I am beginning to think all your posts are satire.

Tell me about. But he does get serious too sometimes.

Maybe he is suffering from split personality.

:dontknow:

 

[Bernard SG]

Why don't you just shut up?

EDIT: Someone needs to innovate a cyber punch; but yes, without the ****ing sandbox.

On a very similar note, is apple going to limit access to the terminal? I love OS X. It is the best operating system for almost anyone except for hard core gamers. The underlying UNIX is a blessing and I don't want Apple to take it away even though 1% of OS X users use it.

OS X is for the pros. Don't dumb it down for **** sake. iOS needed it. The use case was different as compared to OS X. Please Apple don't **** up. I'd still got to buy a mac as Windows suck but please care about all of us.

ffs

Relax, there is nothing, I mean, really NOTHING that indicates OS X would undergo alterations in terms of its UNIX foundations.

This is a Mac App Store issue exclusively. And at this point in time, outside Apple's own software, I would think the majority of applications running on the Mac are not coming from the Mac App Store.

This story is really overblown. Of course, it's not going to make developers happy that they have to re-work their product to make it comply to the 'new' rules, but in reality those rules are not that new. It was pretty much clear from the launch of the MAS where things were going.

There's an article in Ars where some developers weigh-in:

Agile Bits was quick to add sandboxing support to its popular password locker app 1Password in anticipation of the original November deadline. While it took some work on the company's end, including a removal of some functionality and flexibility from the software, Agile Bits believes it was the right way to go.

"We're on board with the approach that customers shouldn't have to care about things like where their files are," Agile Bits spokesperson David Chartier told Ars. "Now that we've implemented it, down the road it's going to eliminate a ton of customer service problems for us, such as people putting their password store in a nonstandard place and then end up accidentally putting it in the trash or deleting it."

For instance, sandboxed apps can't open and close files in arbitrary locations on a user's disk without using the standard open/save dialog boxes. So, for 1Password to automatically open and write to its password database, it has to keep it in a special file system location that only it can use. This is similar to the restricted file system access imposed on iOS apps.

"A small portion of our power users are upset [about the change]," Chartier said, "and I think there are a few things Apple could do better to make things easier on both sides. But in general, we like the idea of sandboxing because its advantages in general security and simplifying things for the end user are worth it."

Bare Bones Software's Rich Siegel agreed that, in principle, sandboxing will benefit a majority of users. "Sandboxing is an excellent solution for the security issues that would otherwise cause Mac OS X to turn into a malware cesspool," he told Ars, "and without subjecting users to a numbing progression of 'Cancel or Allow' dialogs that habituate the user to click 'Allow' in order to get useful work done."

"For 99.44 percent of the applications out there, sandboxing is a workable technology, whose adoption curve is very flat and low-friction, and whose users won't notice any functional difference," Siegel said. "Our Yojimbo largely fits in to that category, I think. It's more of a consumer-level product of the sort that I believe was in mind when Mac OS X sandboxing was designed."

 

[shadowlawless]

Sandboxing is quite the contrary. It encourages developers to be sloppy, because "hey, we're sandboxed anyway, nothing bad can happen right ?".

Not to mention it dumbs down the applications because they can't use things like IPC, hardware interfaces and other OS functions to communicate with the outside world outside of the subset provided by Apple.

No really, if OS X ever forces this model of sand boxing, it's the end of it for me.

----------



Yeah, sometimes it's fun having the app do everything automatically, without the user having to navigate in a file dialog box. Autodiscovery of media is a "nice to have". With Apple's sandbox, it's an "impossible to have".

That's only true if you assume apple does not provide substitue ways of doing the things you speak of. Just how apple has provided a way for apps to access files the user wants to save/open from, is it not possible for Apple to allow a single process access to the 1 folder it needs to auto read from? for example auto read process can Read from music folder to popultate songs. this process would be considered safe because all it can do is "read" from the folder and the app still remains sandboxed.

is it not also possible for apple to create new ways of doing everything the old apps used to do. I doubt Apple's end goal is to remove all useful functionality to apps.

as for your other comment In a way i understand that what your saying about people not worrying about things so much,making them lazy, but isnt that how all developing gets better?

think about it when everything was coded in machine code, if the developer had to "not be lazy" and develop in machine code, they'd have so much to think about that they would never have the time or resource to implement the sort of features we have now. its only because of great libraries, API's, and innovative coding sofware which removes all of the hassle that apps are able to do so much now.

so in that respect , by developers "being lazy" about doing stuff which the OS can handle like security and threading (which can now be handled by Apple's GCD) , allows them to concentrate on innovating. rather than coding.

 

[haravikk]

"Processing arbitrary files" is exactly the point of an FTP program.

I know that, but the point of sandboxing is that you break the application down into smaller pieces, with each piece only requesting the privileges that it requires.

So, for example, in Transmit, you might have:

• FTP Engine - requires network connection privileges, and access to temporary file-storage only.
• File Handling Engine - moves files into or out of the temporary area to arbitrary locations. Requires full file-system access, but since it only handles move/copy/replace requests from the controller then this should be safe.
• Application Controller - issues commands to the two other parts, but beyond process communication it requires no privileges, and so can be fully sandboxed, preventing it from becoming an attack vector.

This point is that it should be possible to break up nearly any application into the parts that require "high risk" privileges like arbitrary file-system access, such that they do so in a controlled, non-exploitable way.

For example, if a bad FTP command were processed by Transmit in the above structure, then at worst it would result in a file being downloaded into a temporary location; unless the controller doesn't bother to verify the actions of the other components, then this shouldn't be able to trigger a malicious action in the file-handler.

It's a greatly simplified example, but this is the whole point of the entitlements scheme added in Lion, which controls how applications are sandboxed.

The example that is frequently given is Quicktime which could (or may already) be structured like so:

• File Handler - opens and saves quicktime files.
• Media Player - process and displays video and audio data streamed from the file-handler.

The file handler would have limited file-system access for opening and saving, while the media player would have no privileges at all, meaning that all it would do is play the media, so even if a code exploit were embedded in the media file, it would have no privileges so wouldn't be able to do any damage to the system.

 

[MacRohde]

I know that, but the point of sandboxing is that you break the application down into smaller pieces, with each piece only requesting the privileges that it requires.

So, for example, in Transmit, you might have:

• FTP Engine - requires network connection privileges, and access to temporary file-storage only.
• File Handling Engine - moves files into or out of the temporary area to arbitrary locations. Requires full file-system access, but since it only handles move/copy/replace requests from the controller then this should be safe.
• Application Controller - issues commands to the two other parts, but beyond process communication it requires no privileges, and so can be fully sandboxed, preventing it from becoming an attack vector.

This point is that it should be possible to break up nearly any application into the parts that require "high risk" privileges like arbitrary file-system access, such that they do so in a controlled, non-exploitable way.

For example, if a bad FTP command were processed by Transmit in the above structure, then at worst it would result in a file being downloaded into a temporary location; unless the controller doesn't bother to verify the actions of the other components, then this shouldn't be able to trigger a malicious action in the file-handler.

It's a greatly simplified example, but this is the whole point of the entitlements scheme added in Lion, which controls how applications are sandboxed.

The example that is frequently given is Quicktime which could (or may already) be structured like so:

• File Handler - opens and saves quicktime files.
• Media Player - process and displays video and audio data streamed from the file-handler.

The file handler would have limited file-system access for opening and saving, while the media player would have no privileges at all, meaning that all it would do is play the media, so even if a code exploit were embedded in the media file, it would have no privileges so wouldn't be able to do any damage to the system.

Since we must assume Apple revokes the temporary entitlement to arbitrary file access, how can the FTP program show a browser where the user can choose which file to upload. It doesn't seem possible, unless you use an open dialog, which is poor poor usability for a FTP program.

 

[shadowlawless]

The thing is, what apple is trying to do is less like micromanaging or controlling, and more like setting rules and regulations to ensure quality of the apps. When a product is made, before it is released it usually has to pass certain tests to ensure it is of high quality this is no different.

What apple wants is for each "process" within an "App" to only have access the exact resource it requires. All it means is that each "process" will not have access to everything that the "application" has access to. this way all processes are harder to exploit, (which is how hackers install virus' ect) also allowing each process to be shared out between cores on a computer increasing efficiency and speed of the app running. it also means if any of these "processes" crash, the "App" can keep running and the "processes" can be restarted, reducing the probability of crashes.

for example

"A process that's decoding video probably doesn't need any access to the file system, the network, the built-in camera and microphone, and so on. It just needs to accept a stream of bytes from its parent process (which, in turn, probably used Powerbox to gain the ability to read those bytes from disk in the first place) and return a stream of decoded bytes. Beyond this simple connection to its parent, the decoder can be completely walled off from the rest of the system. Now, if an exploit is found in a video codec, a malicious hacker will find himself in control of a process with so few privileges that there is little harm it can do to the system or the user's data."

http://arstechnica.com/apple/reviews...os-x-10-7.ars/

As for accessing the rest of the system

"Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action".

http://arstechnica.com/apple/reviews...os-x-10-7.ars/

it just means that the app will require the "USER" to request access then an entirely different sandboxed process (Powerbox) will access other file systems for the app. which makes it even harder for hackers to exploit apps to install virus' ect. only downside is that developers will have to work a lot harder, which is to be expected if the developer wants a more secure, more efficient and all in all better App

what apple is trying to do is eradicate sloppy coding and i think its a great idea, and will set a new standard for developing in the industry.

some people might say taking a low of lower level stuff out of developers hands is restrctive and can make them lazy as they dont have to worry so much. but That's only true if you assume apple does not provide substitue ways of doing the things you speak of. Just how apple has provided a way for apps to access files, it's also possible for apple to create new ways of doing everything the old apps used to do. I doubt Apple's end goal is to remove all useful functionality to apps.

as for dumbing down developing, think about it when everything was coded in machine code, the developer had to think about so much that they never had the time or resource to implement the sort of features we have now. its only because of great libraries, API's, and innovative coding sofware which removes all of the hassle that apps are able to do so much now.

so in that respect , by developers "being lazy" about doing stuff which the OS can handle like security and threading (which can now be handled by Apple's GCD) , it allows them to concentrate on innovating. rather than coding.

 

[KnightWRX]

That's only true if you assume apple does not provide substitue ways of doing the things you speak of. Just how apple has provided a way for apps to access files the user wants to save/open from, is it not possible for Apple to allow a single process access to the 1 folder it needs to auto read from?

https://forums.macrumors.com/posts/13785303/

That is all.

 

[Stella]

Why did you post the exact same content no one less than three occasions?

You reference machine code in your psot- applications ( ignoring games ) were rarely coded in full using machine code ( and this hasn't happened in a very, very long time ). People used the likes of C, Cobol, Pascal, ADA, and even BASIC. And yes, APIs were still there available for use, more so than others - depending on the platform. Coding an application in machine code would simply cost too much in terms of time and money - thats why other, more suitable languages were used.

You need to define what you mean by 'sloppy coding'. Most developers take pride in what they are doing and would love to produce 100% perfect code, however, due to other pressures, this isn't possible. So, in your eyes, what is 'sloppy coding'? Additionally, trying to make an application secure as possible is not simple, sure there are 'low hanging fruit' measures you can take, but it can soon become complex.

Apple aim is to make Lion as secure as possible via sand boxing.

The thing is, what apple is trying to do is less like micromanaging or controlling, and more like setting rules and regulations to ensure quality of the apps. When a product is made, before it is released it usually has to pass certain tests to ensure it is of high quality this is no different.

What apple wants is for each "process" within an "App" to only have access the exact resource it requires. All it means is that each "process" will not have access to everything that the "application" has access to. this way all processes are harder to exploit, (which is how hackers install virus' ect) also allowing each process to be shared out between cores on a computer increasing efficiency and speed of the app running. it also means if any of these "processes" crash, the "App" can keep running and the "processes" can be restarted, reducing the probability of crashes.

 

[KnightWRX]

You need to define what you mean by 'sloppy coding'.

Apple aim is to make Lion as secure as possible via sand boxing.

And again, Sand boxing is a band-aid to sloppy coding, it does not promote quality of applications, I don't know why people say Apple's aim is to enhance the quality of applications, because frankly Sand boxing does everything except that.

Sand boxing is a way to prevent application missbehavior from having an impact on the rest of the system, at the cost of flexibility in those applications.

 

[MacRohde]

Sand boxing is a way to prevent application missbehavior from having an impact on the rest of the system, at the cost of flexibility in those applications.

That's a pretty good summary.
Shipley's idea of using certificates is pretty good (http://blog.wilshipley.com/)

 

[Stella]

And again, Sand boxing is a band-aid to sloppy coding, it does not promote quality of applications, I don't know why people say Apple's aim is to enhance the quality of applications, because frankly Sand boxing does everything except that.

Sand boxing is a way to prevent application missbehavior from having an impact on the rest of the system, at the cost of flexibility in those applications.

Yes, your correct. I don't understand how the poster thinks sand boxing will improve software quality, and how it will be "ground breaking", he used other words, with the phrase "sloppy coding" ; sloppy coding can be a great many things - and sand boxing won't improve many of the traits that fall under the wide definition of "sloppy coding" .

Like I said in the post you quoted, sand boxing is to make the OS as a whole, more secure.