Developers submitting applications to Apple's Mac App Store will soon be required to add an extra layer of security for their wares to be accepted. Beginning in March, all apps submitted must implement sandboxing, a protection that tightly restricts the way applications can interact with other parts of the operating system. By …
Surely if sandboxing is meant to keep applications in their place then it's up to the OS to allot any resources to it? Is sandboxing an individual application sometifng which anyone can do flawlessly, so that every application not by a malicious provider will be an inpenetrable prison for any scripts or shellcode trying to break out?
This all sounds a bit odd to me.
Why doesn't Apple simply host apps in a sandbox instead of relying on every dev to do it.
...meaningful sandboxing profiles must be customized to the application in question. I guess Apple does not want to interfere with something that should be done by software vendors themselves.
"Why doesn't Apple simply host apps in a sandbox instead of relying on every dev to do it."
They do, in a manner of speaking.
You can't just stick every app in a sandbox and allow no interaction with the outside world; if you do, apps can't read and write files, communicate with the network, and perform other functions.
And if you're an operating system vendor, you don't know whether or not a particular application needs certain system resources for its normal job or not. An app is trying to connect to a server at a certain IP address; does that mean the app has been hijacked, or is the app an FTP program? As the operating system vendor, you can't tell. You need the app to tell you.
Implementing the sandboxing in an OS X app is relatively straightforward in most cases. Without going into the technical nitty-gritty, basically you click a tickybox that says "Sandbox this app" and then you create a list of things which the app should have access to ("This app should be able to save files," "This app should be able to read files," "This app should be able to access the Internet," "This app can access the attached Webcam," and so on. (Apple refers to each of these things as an "entitlement." You make a list of the entitlements your program has to have in order to function. If it attempts to do something not on the list, it's not allowed.)
Since the developer knows what his app needs to be able to do, it's up to the developer to list the entitlements and turn on sandboxing. You can't simply turn on the sandbox without any idea of what the app needs to do.
Getting out of the sandbox is the trick
Apple aren't relying on devs to implement sandbox protection. The changes needed are for apps to continue to work once the sandbox is in place.
In particular, for apps that need to do things like opening files - there is one protected way to put up a file selection dialog for a sandboxed app and if your app doesn't use that it will not work.
Am I missing something completely obvious?
So some new trojan says 'gimme everything' to the OS and gets it.
Unless sandboxed apps must be verified and signed by Apple. If (when) sandboxing is made mandatory for non-App Store software in the future then we're yet another step in the road down iOSation of MacOS X.
They're not sandboxed now?
I assumed they already were. It is unnerving to think that I could download something from the Mac App Store on a whim that can have almost complete control over my computer (certainly all of my valuable information). Good thing I haven't used it yet.
Most things you'd download aren't sandboxed... Why would you expect the app store to be different.
If your app can't be sandboxed...
Then don't sell it in the App Store. Simple enough, really. There's nothing to stop you distributing it through other means. Apache server isn't in the App Store for a reason.
@deains: "Apache server isn't in the App Store for a reason"
Yes - because it's already installed with the operating system.
Well Done Apple !
Could Mr Shuttleworth of Ubuntu now please do the same for his operating system ?
Clearly the Secunia guy(s) had no clue
..or they'd have known that DEP is irrelevant to the Java JVM. The JVM works by interpreting bytecode (and for all I know single-steps JIT output since that would still be a lot faster than bytecode interpretation) which means that:
(1) the bytecode generated by javac is just data to the host OS since it can't be run by the OS. All that can happen to it is to get read as data and interpreted by the JVM, which IS a binary executable within the meaning of the act. The OS neither knows not cares that bytecode is going to be interpreted by the JVM. Since the JVM reads the byte code as data and will apply its own rules to prevent access outside the memory regions the JVM has allocated as stack and heap data space, DEP is simply irrelevant.
(2) the JVM allocates and manages all access to memory containing byte code, the stack and heap, ASLR rules also become somewhat irrelevant since the JVM interpreter will use ASLR in OSes that support the facility and, anyway, applies its own sanity checks first, so it will spot an out of limits data reference before it gets bounced off the ASLR gatekeeper.
(2) the JVM is a normal executable that happens to do a number of things as the result of reading the bytecode - WHICH DOESN'T MAKE THE BYTECODE EXECUTABLE TO THE OS
Cameron is right too: implementing DEP and ASLR checks over the head of any program (user-land or not) is entirely OS business: any OS that leaves these checks to a program its running is shockingly badly designed.
This isn't exactly recent news either, boys and girls: mainframes have done this since 1964. No, I don't mean the IBM S/360 schlock, but the ICL 1900 series, which always used zero-based addressing within a program regardless of the address a program was loaded at: the OS knew the datum and limit values for every program and restricted all program addressing (for both data and instructions) to that range - and yes, even in the 60s a running program could be and typically was moved in memory while it was running and could also be stopped, swapped out to disk and back in to (probably) a different memory region without knowing that it had been stopped or moved.
Isn't sandboxing the responsiblity of the OS?
It is indeed the responsibility of the OS and so it will be... on March 1st. What Apple are announcing is not that they will require developers to write their own sandbox, but that *all* applications built after that date need to support the sandboxing model of OS X if the developer wants to sell it in the Mac App Store.
The OS defines and enforces the sandbox, but it is up to the app developer to specify the boundaries of the sandbox. Does the app require access to the Internet? File access? Access to other applications? The developer needs to explicitly define these requirements, what Apple call "entitlements," in order for the app to work within a sandboxed environment.
That is the new requirement, not that developers have to roll their own implementation of a sandbox; and the system already provides a nice API to do this which developers are ignoring.
... will kill innovation. Too high walls, too much security overhead.
They don't want developpers to be able to DO BETTER on their own hardware.
That's why nothing major is never done on Macs, if it doesn't come from Apple.
are you all right?
Good point, because the Windows security model has been SO much better ...
And they said...
...Jobs was the one with sole domain over the reality distortion field...apparently they were wrong, as your post so neatly proves.
That's quite a logical leap you've made there.
Adobe won't like that!
Imagine a flash player or PDF reader without all the possibilities to highjack the system with actionscript.
Beer, this will be a funny friday afternoon :)