Mac App Store Sandboxing Requirement Pushed to March as Uncertainty Looms

[shadowlawless]

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

That is all.

These are the entitlements an app can access "directly"

"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."

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

using trusted daemon processes an app can access whatever it wants "indirectly", it just means Apple has more work to do creating these trusted daemon processes. at the moment i don't know how many there are or what they're capable of, but can you honestly think Apple, builder of the already virus free OS has an end goal of removing loads of application functionality JUST for security issues that are already almost non present?

I highly doubt it. as i said before i beielve their end goal is to create a standard of programming for macs which will overall improve security and effeciency.
and if they do manage to replicate what older type apps can do using trusted daemon processes, it WILL benefit the platform hugely.

 

[kps]

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

That is true, but meaningless; iOS has the same foundations.

Re-quoting from Ars:

... it took some work on the company's end, including a removal of some functionality and flexibility from the software .... “A small portion of our power users are upset”

Just like Xserve, FCP, AutoSaveDestruct, and the Mac Pro rumors, a “small portion of power users” are upset. We use Steve Jobs’ “trucks”, and for us, the writing is on the wall.

 

[Stella]

These are the entitlements an app can access "directly"

"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."

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

using trusted daemon processes an app can access whatever it wants "indirectly", .

And what does this solve exactly? This requires user interaction, like (Knight? ) said previously, an application cannot access such files automatically. So much for software usability.

The inclusion of this daemon won't solve other issues that are present in other applications that contain functionality not allowed in the sand box environment, and I'll use Transmit as an example.

 

[MacRohde]

And what does this solve exactly? This requires user interaction, like (Knight? ) said previously, an application cannot access such files automatically. So much for software usability.

The inclusion of this daemon won't solve other issues that are present in other examples, and I'll use Transmit as an example.

This trusted deamon simply opens the open/save dialog, and punches the hole through the sandbox. And yes it is iniitated by the user.

----------

The inclusion of this daemon won't solve other issues that are present in other examples, and I'll use Transmit as an example.

Yeah it does nothing for something like Transmit. Unles you want an open dialog so you can choose every file via the dialog. Imagine transfering a 1000-file website this way. Oh joy.

 

[shadowlawless]

And what does this solve exactly? This requires user interaction, like (Knight? ) said previously, an application cannot access such files automatically. So much for software usability.

The inclusion of this daemon won't solve other issues that are present in other examples, and I'll use Transmit as an example.

yes that daemon process does. but that one is the only one mentioned in the article and it is in charge of using dialog boxes to save/open files anywhere on the mac. and it doesnt say that is all that particular daemon is capable of.

notice how that list doesn't have an entitlement for full access to all files on the computer, and yet you can save a file anywhere you like?

thats what the daemons are for giving apps access without handing over the whole sytem to the app, and the article doesnt say it is the only daemon of its type. ofcourse some process require more than just pictures folder ect (like saving and opening files) but that doesnt mean apple is going to prevent them from accessing the files all together.

think about it

 

[kps]

Forbes: Apple's Mac OS Lockdown To End Developer Independence

Software distribution is taking on the flavor of the Hollywood studio model, where a half dozen large firms (e.g., Warner Bros. and Paramount) control all dissemination. The arbitrary whims of Apple, Microsoft, Google, and a few others will determine which software sees the light of day and which stays in the attic. Their competitive goals will prevent some genuinely disruptive, innovative software from emerging — outside their control.

The longer-term consequence? A lack of innovation in consumer software.

 

[MacRohde]

Forbes: Apple's Mac OS Lockdown To End Developer Independence

This is exactly what is gonna happen.

 

[KnightWRX]

These are the entitlements an app can access "directly"

Which is the point. If a user has to click confirmations or use Open/Save dialog all the time, it's not quite convenient now is it ? Why would I want apps to automate my workflow and tasks when these apps require constant baby-sitting and manual interventions ?

Again : Sand boxing is a security feature that is there to control missbehaving applications from affecting the rest of the system, but it comes at the cost of flexibility in applications.

I wouldn't run all my processes under BSD jails on a server, but it makes sense to isolate from of my processes, as long as they don't need to reach out. On my desktop, I want my applications to do as much as possible in as "out of the way" method as possible. I don't want to click through endless "Open/Save" dialogs to manage files on a network share because it's not a "use case" for Apple's special daemons.

----------

This trusted deamon simply opens the open/save dialog, and punches the hole through the sandbox. And yes it is iniitated by the user.

So if I want my Music library management application to scan through my mounted network volumes and my local volumes for Music files, I would need to click through every file using the Open/Save dialog.

Either that, or use one of the approved Apple folders for storing music (which might not be on the network at all).

Again guys, Sand boxes = good in certain use cases. Forcing sand boxing of everything = bad. MAS = crap quick and dirty applications. Let's hope they don't go farther than the MAS with this thing because seriously it would kill OS X's flexibility and power, for the sake of not even raising application quality, just hiding away the "sloppy" coding in the sandbox.

----------

notice how that list doesn't have an entitlement for full access to all files on the computer, and yet you can save a file anywhere you like?

As long as you have the user go through the Open/save dialog. Again, what part of "automation" don't you get ?

Look, it's fine that you want everything sand boxed on your computer, but don't go telling us it's fine for everything and everyone. I'd rather my applications be able to do actual stuff on my computer without having me having to click through tons of stuff or having Apple "approve" its behavior.

Thank god I can still ignore the MAS like I've been doing. Apple is not helping me warm up to their idea.

 

[Stella]

yes that daemon process does. but that one is the only one mentioned in the article and it is in charge of using dialog boxes to save/open files anywhere on the mac. and it doesnt say that is all that particular daemon is capable of.

notice how that list doesn't have an entitlement for full access to all files on the computer, and yet you can save a file anywhere you like?

thats what the daemons are for giving apps access without handing over the whole sytem to the app, and the article doesnt say it is the only daemon of its type. ofcourse some process require more than just pictures folder ect (like saving and opening files) but that doesnt mean apple is going to prevent them from accessing the files all together.

think about it

I am thinking about it: It solves one problem - allowing the user to select files and directories that would normally be off limits to a sand boxed application.. You keep on referring to it as if its a wonder cure for ALL sand boxing issues.

I highly doubt it. as i said before i beielve their end goal is to create a standard of programming for macs which will overall improve security and effeciency.

It is perfectly possible to write a sand box application that is accepted to the AppStore that has poor performance ( i.e., "slower than expected" ), which would fit one of the definitions of "( lack of ) Efficiency"

How does sand boxing make applications more efficient? Again, "efficiency" is a very broad term, as is "Sloppy coding".

So, please, define what you mean by "Sloppy coding" and "Software efficiency".

I get the impression you are using those terms in a "buzz word" fashion.

 

[shadowlawless]

If a user has to click confirmations or use Open/Save dialog all the time, it's not quite convenient now is it ? Why would I want apps to automate my workflow and tasks when these apps require constant baby-sitting and manual interventions ?

Yes that daemon requires click confirmations. no where in the article does it say all daemons which act on an apps behalf will require user input.,

that particular daemon requires user input because it's used to contol saving and opening files. which makes sense because you dont really want your file saving ect without your nput, especially when apple already offers its auto saving option on mac os x. where all apps can reopen to the exact point they were at before.

but why are you so sure that there will be no other way for an app to indirectly access other stuff usingt other daemons?

like i said, the entitlemeants shown are files an app can access "directly" WITHOUT the use of daeomn process.

p.s for your music you woud go to preferences and set your network folder as the source of music. like you do with most music applications now using a dialogue box. i mean you could just not have sand boxing at all and set your app to scan every drive connected to your computer if you want, and end up with all sorts of random bits of music. but i personally just set the folder i want, or tell the program to add each song i drag onto it into its own folder like in itunes. keeps it nicely organised. i dont see how that's a problem?

 

[KnightWRX]

but why are you so sure that there will be no other way for an app to indirectly access other stuff without the use of this particular daemon?

What's the point of a sandbox if there's a daemon that can permit apps to do anything and everything without user interaction ? Think about that for a while.

Either all these daemons will require user interaction of some kind or the user will have to "whitelist" applications for them or otherwise they are just a useless layer that adds complexity for no benefit at all.

Either the sandbox is strict and requires user interaction/apple approval, or it's completely useless. Either way, the user does not benefit.

Again, I don't think you quite get the concept of sandboxing. It's a trade-off. Added security comes at the cost of flexibility. There is no perfect sandbox where the application can remain as functional and out of the way as it was before.

All your links/wall of texts post just prove this point further. Again, if you like it, that's fine. But don't tell me to like it.

 

[Stella]

Yes that daemon requires click confirmations. no where in the article does it say all daemons which act on an apps behalf will require user input.,

The Powerbox daemon is referred to in KnightWRX link:
https://forums.macrumors.com/posts/13785303/

Sand box applications are still bound by the permissions listed, and multiple cases, those permissions are not enough.

Temporary Permissions issued by Apple are just that - temporary, to fill a void until Apple does something on their part or the developer changes their application to abide by the sand box.

 

[shadowlawless]

What's the point of a sandbox if there's a daemon that can permit apps to do anything and everything without user interaction ? Think about that for a while.

Either all these daemons will require user interaction of some kind or the user will have to "whitelist" applications for them or otherwise they are just a useless layer that adds complexity for no benefit at all.

Either the sandbox is strict and requires user interaction/apple approval, or it's completely useless. Either way, the user does not benefit.

Again, I don't think you quite get the concept of sandboxing. It's a trade-off. Added security comes at the cost of flexibility. There is no perfect sandbox where the application can remain as functional and out of the way as it was before.

All your links/wall of texts post just prove this point further. Again, if you like it, that's fine. But don't tell me to like it.

I know exactly what your syaing but, i didnt say it wouldnt reduce felxibility neither did i say a daemon would be able to access everywhere and anywhere. i said if apple could/has created daemons to find ways of having the functionality other apps have using a sandboxed system (via signing, pre-authorising, app preferences, whatever), which is entirely possible. this is forward thinking, and a step in the right direction.

I know right now it is not perfect, but again i doubt apple's end goal is reduce apps functionality overall and completely remove certain types of apps form their operating system, and if you do think that is their end goal then your being incredibly short sighted

think about it, that doesnt actualy make sense.

 

[TiggsPanther]

that particular daemon requires user input because it's used to contol saving and opening files. which makes sense because you dont really want your file saving ect without your nput

That's not necessarily true. There are time when you do want file operations to happen without your input.

Or, more accurately, without your additional input. (see below)

There is no perfect sandbox where the application can remain as functional and out of the way as it was before.

Exactly.

I use an app called "Screen Grabber" which takes in a video file, or a selection/folder of files, and generated a thumbnail view of it - comprised of multiple shots and some banner information.

Prior to the last update, it would automatically generate a file and palce it in the same folder as the source video.
Ditto for batch processing. In batch mode you select a folder or a group of files and it would then place a a thumbnail in the folder for each video file.
Automatically.

The last update brought in sandboxing. It now opens a second file dialogue box, asking where you want to save the thumbnails.
What used to be a smooth process is now a tiny bit less smooth. OK, it's mainly not a dealbreaker, but it is annoying that I now have to specify for every file or batch where to save thumbnails. In a piece of software where a likely use case is to generate thumbnails for the same folder as the video files.

 

[The Phazer]

I know right now it is not perfect, but again i doubt apple's end goal is reduce apps functionality overall and completely remove certain types of apps form their operating system, and if you do think that is their end goal then your being incredibly short sighted

think about it, that doesnt actualy make sense.

Yes it does. This is exactly what Apple has done en-masse on iOS.

Apple profits hansomely on iOS by virtue of blocking software that might prove superior to their own with App Store restrictions that their own software is allowed to ignore. The strategy appears to be that if you burn competent users along the way then that's irrelevant, as they're not as profitable as the anti-competitive behaviour would be.

Phazer

 

[shadowlawless]

This is exactly what Apple has done en-masse on iOS
Phazer

thats pretty fair. but still the functionality these apps will loose is ridiculous if apple actually make no other way around it???

they must have something in te pipe work right???

your making me worried now, i totally forgot about ios

 

[KnightWRX]

I know exactly what your syaing but, i didnt say it wouldnt reduce felxibility neither did i say a daemon would be able to access everywhere and anywhere. i said if apple could/has created daemons to find ways of having the functionality other apps have using a sandboxed system (via signing, pre-authorising, app preferences, whatever), which is entirely possible. this is forward thinking, and a step in the right direction.

So 2 steps back, 1 step forward. Gotcha.

The point is, the daemons don't restore functionality, they push burden unto the user to interact where no interaction was required before. That's a step in the wrong direction as far as usability goes, no matter what security it brings forth.

And that brings us back to security being a balancing act. Too much security and the flexibility and usability become a nightmare. Too little and the system can get compromised/hosed through misbehaviors.

I believe these Sandboxes are actually too much security. The filesystem already has proper ACL support, so does the device accesses and they are abstracted by proper kernel drivers that can sanitize input/output anyway.

Not to mention if Apple actually introduces so many of these daemons to permit to poke holes all over the sandbox, you're basically back to square 1, with more user interaction and now the following problems :

- These daemons are vectors of possible exploitation even through sandboxed applications. Poking through the sandbox is one thing, but if a sandboxed process manages to exploit a flaw in these daemons (and the more there are, the more probability of holes being found there are), it might get elevated priviledges it wouldn't have had through simply a non-sandboxed application.

- All these daemons will require memory to run, they will need to be active processes, they will need IPC mecanisms. Why would I want to slow down my system ? Can't I just let the application run non-sandboxed instead ? Apple seems to not be allowing the user the chance to "trust" vendors with this scheme. Guess what, I don't need Apple to do hand holding to tell me who I should and shouldn't trust.

I know right now it is not perfect, but again i doubt apple's end goal is reduce apps functionality overall and completely remove certain types of apps form their operating system, and if you do think that is their end goal then your being incredibly short sighted

think about it, that doesnt actualy make sense.

When has Apple done what makes sense ? Apple does whatever Apple wants to do, sense has nothing to do with it. They've done plenty of bone headed moves in the past and while it brought them profit and popularity, it chased away the minority it impacted.

These sandboxes make sense for smallish utility apps that have almost no automation. It makes sense for apps that are self-contained and work on user supplied datasets.

However, you can't force everything into this model. It just doesn't work and it never quite will. Because again, no matter what you try, as soon as you introduce these sandboxes, you've just hit "compromise lane".

 

[shadowlawless]

I stand corrected

i knew apple did things on their own but, generally these things actually made sense in the long run. if what your saying is true this soudns like a bag of hurt.

but what i cant get my head around is why are they so bothered about security now? i know a lot more people are using macs now but, is it really worth the trade off they're binging in.

why bother develop this whole new OS, with so much possibility (if done right) just to tighten up security a bit.

 

[dethmaShine]

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:

I am sorry but I think you are missing out on the implications. I guess very less people are worried looking at the present scenario.
Everyone is worried if Apple is going to control MacOSX like iOS.

 

[FourCandles]

Just some more points that occurred to me since the start of this thread.

1. If Sandboxing is a Lion feature, and all MAS apps must be sandboxed as from March, does that mean that the MAS becomes Lion-only at that point?
2. I understand that sandboxing prevents the app from making unwanted/unsecure/not on the list/whatever interactions with other apps and/or the file system. But presumably (correct me if I'm wrong) there's nothing to stop other processes on the system (e.g. those run by non-sandboxed, non-MAS apps) from interfering with a sandboxed app? Or does a Sandboxed app constantly run some kind of checksum scan on its files to make sure they're not altered?
3. If (2) above is correct and there's nothing to stop other processes interfering with a sandboxed app, then isn't the security advantage of sandboxing negated, unless ALL apps/processes on the system are sandboxed i.e. all have to be from the MAS?

 

[Grumpy48]

This has been an interesting discussion, which reveals a great deal about all of us, me included. Much of this does not depend on fact, but upon perception. This all depends upon where you are watching this total opera. No matter where you watch it, you are watching through *your* eyes, therefore, you develop your own opinion. As you watch and deal with the different issues, you begin to understand, "Uncertainty" is already here and is *not* "Looming". The term, "Looming" is future tense.

I was accurately corrected by "Shadowlawless" Apple Mac can not control the total Apple Mac Ecosystem. The uncontrollable variable is the end-user. Apple can not force acceptance, but they can win him with transparency. Apple and the developers must explain the process and why it's beneficial to the end-user.

 

[hchung]

I stand corrected

i knew apple did things on their own but, generally these things actually made sense in the long run. if what your saying is true this soudns like a bag of hurt.

but what i cant get my head around is why are they so bothered about security now? i know a lot more people are using macs now but, is it really worth the trade off they're binging in.

why bother develop this whole new OS, with so much possibility (if done right) just to tighten up security a bit.

They're making a bigger deal about security because they can. It's always mattered. They just weren't in a position to deal with it because lazy developers had no motivation to listen and go along.

It's matters now even more because networks are much more prevalent, Apple's gaining marketshare and visibility, and it'd be dumb not to put any thought into improving security being a issue when you spent the last 10 years making fun of Windows for ... well not putting any thought into security.

Besides, it's not like sandboxing was invented by Apple. It's an idea that's pretty old and appears in many forms. Wonder why "jailbreaking" the iPhone was named that? Go look it up.

----------

Just some more points that occurred to me since the start of this thread.

1. If Sandboxing is a Lion feature, and all MAS apps must be sandboxed as from March, does that mean that the MAS becomes Lion-only at that point?
2. I understand that sandboxing prevents the app from making unwanted/unsecure/not on the list/whatever interactions with other apps and/or the file system. But presumably (correct me if I'm wrong) there's nothing to stop other processes on the system (e.g. those run by non-sandboxed, non-MAS apps) from interfering with a sandboxed app? Or does a Sandboxed app constantly run some kind of checksum scan on its files to make sure they're not altered?
3. If (2) above is correct and there's nothing to stop other processes interfering with a sandboxed app, then isn't the security advantage of sandboxing negated, unless ALL apps/processes on the system are sandboxed i.e. all have to be from the MAS?

For starters, sandboxing is not new to Lion. I think it got introduced somewhere in 10.5. So no, encouraging sandboxing does not make MAS Lion-only. Sandboxing doesn't require the app be from the MAS either.

It's likely that other processes which arn't sandboxed can interfere with sandboxed apps. But I haven't tried this myself.

If you've got a malicious app which is outside the sandbox and attempt to maliciously exploit an app that is sandboxed, you:
1) you should have tried to pick an easier (unsandboxed) target.
2) would have problems because you're now in somebody else's sandbox and might not be able to escape.
In other words, the effects of such a situation is still better than no sandboxing at all.

 

[michaelcyee]

Forgive me if this has already done, but the requirement of sandboxing suddenly springs to mind this quote: "We have created, for the first time in all history, a garden of pure ideology — where each worker may bloom, secure from the pests purveying contradictory truths."

 

[Otaviano]

Call me crazy, but I think this is a good thing.

 

[djrod]

Forbes: Apple's Mac OS Lockdown To End Developer Independence

Sure, that's why the iOS systems have almost no apps and the few there are have 0 innovation on them.