SYSSEC: June 2007 Archives


June 24, 2007

Nick Weaver suggests that the real "security" motivation for the sandboxing in the iPhone is to preserve the security of Apple (and Cingular's revenue stream):
The sandboxing depends on the objective...

Since the objective is to allow the cellphone company to keep charging discrimatory pricing based on traffic intent (EG, ~80 Mb/$ for bulk best-effort data, but .2 Mb/$ for SMS messages which can actually be worse-than-best-effort), the same origin sandboxing is the perfect policy.

After all, an IM client, at 80 Mb/$ would really hurt the income of the phone company when they could have you sending SMS instead.

Admittedly, this is a fairly plausible-sounding theory (though it's worth noting that AT&T does seem to offer an unlimited messaging plan), unifying, as it does, the sandboxing, and the various pieces of functionality (IM, Flash, turning MP3s into ringtones, etc.) that Apple seems to have decided to omit. But let's imagine for the moment that Apple isn't just trying to extract maximum revenue, but merely to make the iPhone work as well as possible. What sort of sandboxing would be most appropriate then?

In that case, you'd be mostly looking to ensure that 3rd-party apps (henceforth 3PA) interfere with the smooth functioning of the phone native apps (NAs). At minimum, you want 3PAs not to be able to crash the phone. Of course, this functionality is provided by pretty much any modern multiprocessing operating system, and is all you'd really need for most of the apps one the iPhone (Web browser, address book, maps, etc.) But for real-time apps (especially telephony), you probably want better guarantees. In particular, you want to avoid:

  • 3PAs interfering with NA's access to the processor.
  • 3PAs interfering with NA's access to the network.
  • 3PAs interfering with NA's access to the speaker and microphone.

Note that in all of these cases you don't want to deny the 3PA access to the network, just to ensure that the NA gets priority when it needs it. This can be sort of a tricky engineering problem at times but is far from insoluble.


June 20, 2007

It appears that at least initially the iPhone will not have instant messaging, though SMS will "look like" instant messaging (cf. bacon juice vs. lemonade). Because the iPhone is semi-extendable, people are working to close this gap. Unfortunately, since all you can do is write Web apps, this has some limitations. The most important of which is, well, let him tell it:

Log in with your AOL IM account. No data is logged, but all of your information does pass through my server. I am not harvesting any information. This app is server intensive, so I'm limiting sessions to 10 minutes for now.

Obviously, having all my IMs go through somebody's server is pretty weak. Yeah, yeah, I know. I should be using crypto, and I already trust AOL, etc., but that doesn't mean I want to bring another person I have to trust into the loop. Unless I've missed something, this is a pretty inherent limitation of the design decision to only let you write Webapps and to sandbox them in the usual Webapp way. It works fine as long as your goals are limited, but as soon as you want to write something that (for instance) is a generic network client, you're hosed.

Here's Steve Jobs from WWDC:

And so you can write amazing Web 2.0 and AJAX apps that look and behave exactly like apps on the iPhone, and these apps can integrate perfectly with iPhone services. They can make a call, check email, look up a location on Gmaps... don't worry about distribution, just put 'em on an internet server. They're easy to update, just update it on your server. They're secure, and they run securely sandboxed on the iPhone. And guess what, there's no SDK you need! You've got everything you need if you can write modern web apps...

It's probably worth taking the time to unpack the sandboxing issue a bit. The sandboxing used in Java (and Javascript) has two major purposes: (1) to stop the applet from being a threat to your computer and (2) to stop the applet from being a threat to your network. So, when Java won't let an applet write to the disk, that's protecting your computer. When it won't let you connect to anyone other than the originating host (the same origin policy), that's to stop your computer being used to attack other computers on the network. The classic example of this is some applet which you download to your computer (behind the firewall) and then connects to hosts which would be firewalled off from a host on the public Internet.

But of course, if you want to write a real app (an IM or mail client, say), connecting to hosts other than the one you downloaded from is an absolute necessity—unless, that is, you think it's really cool that when you download Exchange you can only send mail to people at Microsoft. So, the idea with sandboxing is that there are a large (surprisingly large, actually) class of tasks that don't need quite so much functionality and that you can then connect to sites that do those tasks without having to think "should I give this program the right to write files onto my disk". But it should also be clear that this isn't the only class of tasks that people want their software to perform. which is why people want to be able to load applications on their computers, even if that whole code signing thing didn't work out as well as we hoped. It's just that you want to have to take positive action before allowing a more powerful app onto your computer (or phone). To the extent to which 3rd party iPhone apps are restricted to the Webapp sandbox, the device is only marginally extensible and that's not really that sweet.

Next: what sort of sandboxing makes sense for a device of this type?