I'd really, really like to see the Apple fanboys try and brush off this.

@Xkeeper: easy all phones run as root.

there is not a phone out there that doesnt. Even PocketPC and WindowsMobile cell phones run as root when everything is set and done.

@Xkeeper: Yeah we're all shaking in our boots over this. *yawn*

@Falconfire: You're holding Microsoft products up as a paragon of good security design? Come on.

Yes, I know the practice is widespread. As a UNIX security geek with a background in embedded software, though, I'm in good shape to call the practice stupid.

That said, this isn't quite as stupid as it sounds. You don't want common applications to replace your firmware, but you do want them to be able to make calls, talk to the Internet, use the camera, read the call logs, and so forth -- because the user can have legitimate reasons for having applications that do those things.

Now, probably what would be a better approach is this:

Sandbox each application. By default, it can access the GUI but can't access the Internet, the GPS, the camera, the phone functionality, or anything else. To get those privileges, you need to either be signed (meaning Apple approved the application) or have explicit user approval for the exact privileges you get. So -- either you get the app from a commercial source who has a key that they paid for from Apple (which can get revoked if they abuse it), or you have free or in-development software which you need to approve privileges for on its first run. Yes, this relies on the user to know enough to be suspicious if the program they just installed to make their screen act like a flashlight is asking to access their GPS, camera and microphone -- but it's a tradeoff which allows room for both Free Software and commercial development targeting the platform, with the user in control of security.

@Charles Duffy: From my limited (not-security-expert) perspective, this is what Symbian does, no? That is, first you need a signed certificate from Nokia to package your app so that it can be installed on a Symbian phone, and then, when you install it, the phone warns the user explicitly that said app is requesting access to camera, Internet, etc.

This certainly isn't foolproof—if an app is appealing enough, and/or you're not overly concerned with security, it's easy enough to grant permission without thinking twice. However, it does put the "key" to the OS in the user's hands.

They should have just made it allowed in the first place so they wouldn't have to work it in at a later date.

It's a cell phone, not a computer. Developing it with user accounts seems somewhat pointless. Root gives the administrators access (though an administrator account is usually better than playing in the root directory) and allows all system functions at the most basic level. You lock down a computer because you want to prevent users from being able do to stupid shit like install software or download viruses. Until we see some real viruses and security flaws for cell phones, we aren't about to see more locked down phones.

As a side note, it is worth mentioning that the plethora of cell phone operating systems has actually helped stop the introduction of viruses to the cell phone. But if one particular operating system begins to gain traction over all the others, and that operating system is particularly vulnerable to hacking, you'll start to see them. Up until now most cell phone viruses have been limited to Europe where users' phones are hijacked to send text messages to a pay number.

@Charles Duffy: Im not holding anything up as good design, just pointing out to the troll that currently all phones run root, regardless of what OS they are running.

Your points are very interesting though and some on the Wired article have already said much the same as you have.

@tedyc03: I disagree, it's a pocket Mac with a built-in camera and phone.

Least privilege isn't just about keeping non-privileged users from installing stupid software. It's about having a priviledged ring that only allows non-privileged users to execute tasks based on a set of rules, like a certificate.

Don't think of the "user" in this case as the person holding the phone. Think of the user as the applications running on it.

Funny how Symbian already enforces this. Applications need to be signed with certain privileges to do anything more than the most basic of tasks.

@Charles Duffy: Great post, and good points all. It seems Apple is looking at some variation of the signed approach. From Steve Jobs's recent announcement on third-party iPhone apps:

Some companies are already taking action. Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than "totally open," we believe it is a step in the right direction.

Celphone applications run as root, yes, but they are digitally signed, and must have specific permissions built into the application in order to pass the rather stringent certification process. If you don't pass certification, you don't get your app signed, and in turn can't be run on the phone.

Permissions in question range from "Does the app need to access the filesystem?", "Does the application need to access the internet?" and so on, and in order to pass the cert process, the app must only request the mimimum permissions that are required for that application to run.

These permissions are built into the signature that the application gets. In this regard, it's much better than simple user accounts, each application has an enforced set of capabilities that they can't get out of - a mini-'sandbox' if you will, as people have suggested.

The OS's on most phones are so bare-bones simple that the overhead required to run user accounts etc just isn't feasible.

In the iPhone's case however, Jobs was bragging over and over in the original announcement how the iPhone 'ran a full version of OSX' - which pretty much gives you an idea of Apples idea of security for OSX as well ;}

It doesn't sound like apple even bother digitally signing or protecting the apps at all, going for the security-through-obscurity routine. Hilarious really.

WHAT. THE. FUCK.

are you insane, apple? ">su root" is the cardinal sin of ANY *nix OS. I mean seriously.....

Translation: Linux, OS X, etc. use a permission system akin to limited, normal, and administrator modes in Windows. "root" is the "God" of the OS that you install. Therefore, running anything with root can lead to some SERIOUS screw-ups.

You don't build an unbreakable bunker only to leave the front door unlocked and unguarded.

A pretty thorough rebuttal of the article is here: [www.roughlydrafted.com]
One major point is that until the SDK comes out in February, no 3rd party software has been running outside of the browser anyways, and so until then this is completely irrelevant.

@4dSwissCheese: That article ignores the facts inconvenient to its premise. Plenty of stuff has been running outside the browser. Have you noticed that folks have been able to unlock their iPhones? They could do that because Apple applications running with root privileges had security bugs. If those applications had access only to the devices they needed through a typical /dev interface, that set of devices probably wouldn't have included the necessary access for firmware upgrades or unlocking (as whatever applications Apple uses for those purposes, which would need some way to get elevated privileges, could be the focus of a tighter audit than the 99% of the code that didn't). Now, in this circumstance, those security bugs are very beneficial to the device's owner when appropriately exploited (a sad departure from the days when every computer came with its own schematics, but that's an entirely different discussion).

Granted, an attacker doesn't need root to do harm -- but if you do per-application sandboxing appropriately (and thus restrict sub-root-level privileges appropriately as well), applications which don't belong in the camera or the address book or $WHATEVER_ELSE can be kept out of there.

I'm not saying that Apple is as grossly irresponsible as some folks are making them out to be over this -- but a quick skim of the "rebuttal" in question leaves it somewhat lacking.

"...and it can't be fixed without a complete redesign of the firmware."

thats not a flaw, its a feature. Probably makes it 2.8 to 3.2x faster than the last iPhone

@4dSwissCheese: Did you actually read the article at roughlydrafted? It's a bunch of observations that have little to do with the problem at hand: by having all applications run with root privilege, Apple knowingly opened a security hole in their phone. That article does not refute that. It begins with irrelevant stuff about how Wired should print iPhone rather than IPhone and follows with what amounts to a series of logical fallacies.

Anybody who's been paying attention knows that roughlydrafted is a site badly put together by an Apple fanboy who has a tenuous grasp of logic and of good argumentation.

As a 37-year-old guy who has used consistently used Apple products for well over 20 years, I have to thank each of you who incessantly refer to "Apple fanboys".

Bless you all. You make me feel so young.

So long the old stagnation that Apple products are entirely secure.

I have to point out that you don't have to run as an Administrator account on Windows, even on XP. You can create a normal user account and log in using that.

The problem is that a lot of applications were poorly written, and assumed that they could write to places on the hard drive or in the registry that they had no business writing to, so that they won't run unless they're run as Administrator.

I set up an old system for my kid to play games on. You'd think that a Winnie the Pooh kid's game wouldn't need admin access to run. You'd be wrong. So my three year old runs as an admin.

So it's not just Microsoft's fault.

I just defended Microsoft. I feel dirty.

Wow. Whoopsie. Even the most paltry of phone OSes have had sandboxes and security for years.

JavaME has a security model and and API for services like making calls, launch URLs, using the camera.

Most phones even have hardware and software tie-ins that prevent modified code from being run. Motorola phones use this model, and people have been trying to hack it for years. Nobody has.

@humphrmi: That makes a bit more sense. Still, I think that in a closed system, the permissions don't matter at all.

I don't think Apple intended to release the iPhone for outside development. I really think they're doing so because they got sued. They're trying to make the lawsuits as moot as possible. By allowing outside development they can't be accused of a monopoly.

And essentially the iPhone system through the browser WAS a user account with limited privledges: you could create applications that ran through the web but were sandboxed from the phone itself for the most part.

@tedyc03: It matters if any of the software in your "closed" system might contain exploitable bugs, and to assume otherwise is foolish.

If Apple hadn't made that assumption, they wouldn't have seen iPhones jailbreaked and unlocked.

@Pasketti: You have this correct. As a MCSD I can say with certainty that application developers write for root/administrator because it saves them time, but if they just took a little extra time their app could be written for a "limited" user account. This is not the OS's fault. It's poor app coding.

Now don't get me wrong, MS releases app SW that actually uses root as well when they too could have written for a "limited" user account. So they take the "short route" as well. But still, this is no fault of the OS.

@anatak: We're talking root, not kernelspace, so there's still context switching going on unless they're doing something funky (and extremely dangerous; memory protection exists for a reason). How do you justify that estimate?

@axiomatic: Meh. Sloppy Windows application developers write for root, but UNIX admins haven't had that expectation for decades. It's a completely different culture. OS X is a UNIX, and one would hope that the folks they'd have writing apps targeted at it are people who understand The UNIX Way.

That said, the "no fault of the OS" argument is specious in an environment where the OS and (approved) applications are coming from the same developer. It's in the same category as Microsoft introducing the new, Unicode-centric win32 syscalls (with the maximum path length restrictions and such lifted) but still using the old, deprecated ones for Explorer.

@tedyc03: It was my understanding, albeit as a somewhat naive consumer, that Apple released Safari for Windows entirely for the purpose of breeding application developers for the iPhone amongst a wider audience. But that's just what I heard. Apple may deny it, but I suspect that they always intended to support third party apps on the iPhone. Which makes this security bug somewhat of a head-scratcher, considering their normally respectable position in the *nix community.

@humphrmi: I certainly don't find Apple's mistake to be very defensable. In fact I wouldn't be surprised if the real reason was because they just got sloppy as they prepped to release the iPhone. Remember the number of programmers they took off Leopard development; chances are good that in the rush to deliver the iPhone they simply stopped being careful. They became a little less Apple and a little more Microsoft in that sense.

This is a non-story written by a reporter who doesn't know what she is talking about.

Yawn. Nothing to see here folks...move along.

I would trust anything Apple made over what Microsoft puts out any day!