Real Security in Mac OS X Requires Apple-Signed Certificates

I think Shipley has missed the point of OS X sandboxing.<p>He's right that sandboxes won't directly prevent malware. But that's not why users want sandboxes. Sandboxes mitigate accidental vulnerabilities. Virtually every security vulnerability you've ever heard about has been an accident.<p>Sandboxes aren't a new idea (the sandbox code didn't even originate at Apple). The idea goes back to the '70s; an obvious and more recent example is the Java applet sandbox, and a somewhat more successful instance is Daniel Bernstein's qmail security architecture (qmail has one of th best security track records of any major software package).<p>It's best to think of sandboxes not as a preventer of malice, but as one incremental form of forced developer competence: all developers are being asked to at least consider what privileges their applications need (most developers do not do this today), so that they can voluntarily renounce capabilities that will be turned against them when someone finds a heap overflow in their code later on. The technology and policy Apple is working with here will do a fine job of that.<p>Also, no matter what Bertrand Serlet said, sandboxes don't need to cover "as many instructions as are in the human brain". Because of its Mach / Unix underpinnings, sandboxes have a relatively simple user/kernel interface they actually need to deal with. There are just a few hundred system calls, many of them already privileged.

The application sandbox should be considered like not storing credit card info on your system... you could do it but you open yourself to security problems. As a developer, you should opt into entitlements because it means that your application will be less likely to have a problem in the future.<p>This is also similar to dropping privileges in unix: if you need sudo to start up, you drop it as soon as possible so that a compromised binary doesn't lead to root access for the malware.<p>They are like fire doors. They don't prevent the fire, they just limit the damage. Anything that encourages developers to adopt the sandbox model is good, however I would say that requiring them everywhere is probably biting off more than they can chew. Furthermore - as Wil explained - being fast with the fire extinguisher is probably a better tactic than trying to monitor and disallow all things that may lead to fire.

I have the greatest respect (nay, love) for Mr. Shipley (who can forget his live twitter coverage of the bachelor), but hasn't web certificate revocation proven to be pretty much un-workable in practice? How would this be different? Entitlements sound similar to code access security which Microsoft baked in to the CLR, but which remain largely un-used.

I would argue that real security requires a deeper approach like QubesOS takes - <a href="http://wiki.qubes-os.org/trac/wiki/SecurityGoals" rel="nofollow">http://wiki.qubes-os.org/trac/wiki/SecurityGoals</a> . Constraining and inconveniencing users for the sake of false sense of security doesn't feel like something that needs to be attempted in 2012.<p>But to be fair - I think the hardware is only now starting to get fast and capable enough for doing security via virtualization. So up until now may be OS vendors did not really have the luxury of thinking along those lines but it doesn't hurt to start thinking now.<p>Apple could really leapfrog if they worked with the hardware vendors to make Mac OS X something like QubesOS but much more usable. On top of it if they had a saner programming language that makes it darn near impossible to make security goof ups, real security still has a chance!

Sandboxing in the appstore is probably not intended to directly protect against malware, it is there to minimize the risk of programmer error. The application developer decides the restrictions it imposes on itself. And while the current entitlements system seems quite weak compared to the normal interface to the sandbox, I think that the number of entitlements that you can request will grow with time, and with user awareness. (The Scheme-derivative that is the configuration right now, is probably not fit for user consumption)<p>The OS X sandbox has been around for a long while (and trusted BSD has been around for even longer), it is of course not bug free, but it is in use in a few exposed applications (like Safari), and deploying it appstore-wide will only make it even better.<p>I, as a programmer, sleeps better at night knowing that my (and others) applications has safety nets that protect it from doing stupid stuff.

<i>"Apple then has the power, if any app is found to be malware, to shut it down remotely, immediately"</i><p>Actually I don't think this will work. They can "shut it down" in the sense that they can keep new installs from happening. But if the malware is already installed it controls the machine, so it can simply ignore the "kill switch" for itself.

Here is the real problem: <a href="http://www.eros-os.org/papers/secnotsep.pdf" rel="nofollow">http://www.eros-os.org/papers/secnotsep.pdf</a>

Does anyone know anything more about this:<p>"Bertrand Serlet once told me that Mac OS X now has roughly as many instructions as we believe the human brain does."

This article by Wil Shipley is grounded in so much real world experience.<p>I too want to develop a Mac app that might not be covered by the existing entitlements and would be disappointed if I couldn't release it via the MAS.<p>Hopefully Apple will read this and consider his insights.