John Gruber speculates on the forthcoming details of the iPhone SDK and makes the following remark with regard to security:

And the hysteria over the iPhone’s current “everything runs as root” situation is overblown. Applications on your Mac don’t run as the root; they run under your user account. But all of your data — your email, your address book, your documents, everything your apps can read or write without administrator authentication — is vulnerable to any sort of hypothetical buffer overflow exploit on the Mac, and would be on the iPhone, too, even if iPhone apps didn’t all run as root. Sure, root privileges allow an exploit to do anything, but the most important thing on your system is your personal data, and an exploit doesn’t need root privileges to access that.

Of course it’s true that an application running as the end user can access any of the end user’s data, but privilege separation remains really important, even for a device like the iPhone. The current iPhone is set up so that anyone can do anything, and Apple keeps things safe by providing a minimal interface to the phone’s features. You can use the applications provided, but unless you hack the phone, you can’t add applications or access the file system. This isn’t ideal, but the lack of privilege separation becomes much worse when there’s an interface available for loading arbitrary code onto the device.

For example, let’s say I’m a spy, and my goal is to record someone’s phone conversations. I decide that the best way to do this is to get a user to install an application that does one thing (pulls down sports scores, let’s say), but also secretly turns itself on anytime they make or receive a call and then stores the audio in an MP3 file that will be uploaded to a server when the phone is idle. Assume that I can get the user to install the Trojan horse onto their phone.

On iPhone of today (where the end user is root), once the Trojan horse is there, I can subvert the software that dials the phone in any way that I choose. I can replace the binary with one of my own creation that records the call, or I can replace the device driver for the audio system with one that accomplishes my goal, or I can alter how the phone software is called to use a wrapper that I created. The bottom line is that I have full access to modify the telephony features of the phone.

On a hypothetical iPhone where there’s privilege separation, all of the phone features are restricted to the “phone” user, and all of the third party applications are restricted to the “end user” user. So when “end user” installs a new application, it doesn’t have any access at all to the things “phone” can do, and so the Trojan horse can’t easily insert itself into the dialing process. That’s a pretty important security feature, don’t you think?

I imagine that the reason the iPhone doesn’t work this way already is that the developers were behind and that Apple chose to punt on the security question to get the phone out the door. Since third party applications are not currently allowed, the lack of privilege separation is tolerable. I’d imagine that by the time the SDK is released, we’ll see a new major release of the iPhone operating system with root locked down and separate privileges for the various functions of the phone. We’ll see.