Android security model is inadequate, and it needs a firewall
sswam.wordpress.com
sswam.wordpress.com
I put together a streaming music player for a community radio station, and published it on the market. I want to be able to detect when the phone rings so I can kill the music. In order to do this, I need to request permission to "Read phone state and identity."
Once I've requested this permission, I can gather all this other data:
http://developer.android.com/reference/android/telephony/Tel...
I can request their IMEI/IMSI, their phone and voicemail numbers, the name of the cell network they're registered on, and the cell site they're talking to. This is too much! At the very least, the "read identity data about your phone service" should be separated from "find out if the phone ringing is or a call is in progress."
There are a large number of apps that request this particular permission. For example, why do Facebook, Amazon Kindle, Yahoo Fantasy Football, and OpenTable need access to this feature? These are all large brands that would suffer some hefty damage if they were found to be surreptitiously pulling user info, so I'm assuming they have a legitimate need for that permission that doesn't involve sniffing data. I want to know more clearly what business they have poking at the telephony manager.
Access personal data
- FooBarApp accesses your contacts to send and receive them
over Bluetooth when requested.
It's certainly not ideal but I doubt that users are even paying attention to the permission dialog as it is.
A fun experiment would be to publish an innocuous free app that requests every single permission for no apparent reason. I wonder what percentage of users would actually decline to run it.
If I write a Windows (or Mac OS X, or Linux, to a slightly lesser degree in each case) application, I can have that app do every bad thing proposed by the author, and much more. I can roam through their "Pictures" and "Movies" folders, send out stuff I find over the probably very high speed internet connection. I can run proxies or other malware. I can pretend to be other applications to sniff passwords, or for other nefarious purposes, etc.
That is, of course, a major failing of the security model in a desktop environment...and it's been responded to by lots of band-aid solutions, like anti-virus and malware detection tools.
In short, while I think it's sort of unfair to pick on Android (which has among the best security layers built into the OS, rather than into the application distribution process or based on vendor trust), I actually agree. The new mobile device OS is an opportunity to solve the major security issues we know about. It shouldn't be a situation where backward compatibility is allowed to stand in the way of mitigating serious security risks.
The SD card thing could be fixed by deprecating 1.4 behavior. I wouldn't think that'd be a major issue, since a large number of apps had to be updated for 2.x anyway.
It would be great if a user could sandbox those permissions or even outright block them, but I guess that would just lead to malconfiguration, confusion and blind bug reports. Maybe a custom mod will do it some day. I rooted yesterday and now have an iptables based firewall installed that lets me control what applications can access the internet (I guess there are loopholes around it but it is better than nothing).
Also, there is a way to completely disable net access temporarily: APNdroid kills the wireless data over 3G/EDGE/GPRS and then disable wifi. This kills in-game ads but who knows what data the app stores up for future transfer.
Your title should have been "Mobile OS's security models are inadequate- and out line how Android, iOS etc could be improved upon.
The way you wrote it feels FUD-y :)
First off, if you've got a user who is trying to install the app, it's extra clicks and text that they're going to ignore anyhow. They trust you, they're installing your app, don't be an asshole.
Second, say you don't need GPS or something for your product's current state, but you'd really like to integrate with something that will need it. Handling all the states of old user without perms -> new user with perms ( asking for permission? refusing without? what about when they decline? ) is a huge headache of busy work code. Get them to add that permission while they're already clicking and ignoring the legalese, and everyone wins.
Yes, we read the permissions apps use, but we should all realize that our parents won't. As long as you're allowing people to execute arbitrary code, on your outsourced hardware, broadcast over a public network, there's some diminishing returns on security. You're putting really fancy padlocks on a screen door.
It looks like compiled apps on Palm can also read the whole media directory. The neat thing with Palm though is any app can bring in scenes (a screen) from other apps, preserving the state of the application underneath, while passing back data. This way any app can selectively share with another app. On iPhone OS the only system wide widgets available are provided by Apple. I'm betting/hoping Palm will come back and give Apple a run for it's money, if the carriers don't cripple it somehow first.
iPhone apps have been able to access camera roll images by direct file access. I think they are still able to, though I didn't verify that.
It wasn't even difficult at all, a path to the photo directory can be easily figured out either from the simulator's file system or by jailbreaking the phone. (Or nowadays by Googling)
Secure sandboxing is pretty difficult thing to do properly.
If the image picker UI widget has an access to your photos and it is running inside your applications process, then your process has access to those files. It doesn't matter if the actual path is hidden, a clever hacker could still figure out to get access to those files.
To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app. This is non-trivial to implement well, given that UI transitions are expected to be smooth and even support animations.
Due to the API design of UIImagePickerController, I think Apple has known this from the beginning and maybe planned to do it securely. But I assume they just haven't got time to implement it yet.
Android already does this using separate processes for distinct Activities and by using Intents for message-passing between those activities. Granted, Android doesn't prevent access to the SD card data, but assuming it did secure that access somehow, the existing Activity/Intents framework would make it trivial to keep that functionality separate. Except for the fact that all the system applications and activities are built on top of the same basic Android SDK/API as 3rd party applications, so anything they can do, your apps can do too if it requests the right permissions.
I am surprised the images aren't accessed through another process that has directory access but enforces limits. Couldn't that process just allocate a buffer or take a pre-allocaed buffer for a UIImage and pass back a pointer to the requesting app? Is there some sort of technical limitation that forces it to send the image back via a slower method like IPC? Sending a message to the managing process to get the image and receiving a pointer back shouldn't have too much overhead should it?
I read on Ars that hardware virtualization support is coming to mobile at some point. The ability to trap the right instructions so an app can't break out should hopefully help secure these kinds data stores without having a curated app library, and without too much of a performance hit.
I thought we were there already there, so this is dissapointing. For some reason I am less comfortable with my phone apps having the sort of file system access than my desktop apps. Restricting internet access for apps in order to control data from leaking out is too far reaching, lots of apps need internet for things besides stealing data.
I understand why Apple likes the App Store model and process, and the huge revenue they get from it. But I have never understood why any developer or consumer would consider it a benefit that outweighs its many negatives (higher costs, slower development, limits on application capabilities, extreme difficulty deploying custom apps, inability to develop applications that compete with Apple products, etc.).
It doesn't require a curated market to kill off 1.4 API features. A new version of the OS can do that, as can standards for permissions. Why would you believe having standards imposed by fallible humans with a limited view of the application could ever do a better job than the OS itself? Assuming the decision was made to correct these security risks, it's obvious, to me anyway, that doing it in software is the only reasonable way to do so.
The objection to the app store, in my mind, was always not that it was highly curated by people, but that it was highly curated by people and there was _no_ other way to install software.
Again, this is something with an obvious software solution. Google is the best in the world at providing good search results...so, why not provide the best search results in the market? (I don't think they currently do a good job, though. I'll be the first to admit that the Apple App Store is still a somewhat better experience than the App Market, despite App Market getting quite a bit better during its life...but it's not because App Store is curated. It's because Google hasn't put the resources into making App Market work really well.)
Generally, I think if you've got people involved in processes that could be handled by software, it's a failure. It's costing consumers more money, costing developers more time, and insuring that it is a fallible process and subject to the whims of sometimes capricious reviewers. Since this article is about security (and not "~~~FREE RINGTONES~~~"), that's clearly something that ought to be handled in software. The fact that Apple doesn't handle it in the OS, and instead relies on human reviewers, is Apple's failure. The fact that Google doesn't handle it in the OS, and relies on vendor trust and user intelligence and a better than average (but still weaker than ideal) security model, is Google's failure.
On the subject of security, you've suggested that Apple have the problem solved by having a curated market. I don't believe that's at all accurate.
Comparing Android to Windows in terms of it's security vulnerabilities? There are some fair comparisons, but the better comparison is how it is more likely to become a platform littered with unwanted apps from carriers and third parties. I wouldn't be surprised at some point to see Apps the "bundle" other apps.
People don't pay attention to all the words that flash on their screen before an app is installed. They just want the app.
Having a better managed app store would be a big step in the right direction.
As for disabling net access for "free" games that you want to play so that they don't display ads, the current focus on free and $0.99 apps really leaves the developers who put time in little other recourse to make money. (I'm not saying all free/cheap apps are of the same caliber, some are great and some are "not scottish").
The average user does not think up malware exploit-cases to convince himself that full internet access combined with the universal implicit 'read anything off the SD card' permission is not a good thing. He just clicks the funny rubber cow and listens to the moo sounds!
If games want to display ads, that would be okay, but they need a more limited permission which gives them internet access to their home server only (like java applets) and no access to local filesystems except a little space for their own settings and files. I think there should also be a declaration of ad-spamminess in the manifest so that people can avoid such games. I really don't trust random closed-source freeware games with my filesystems.
If you really want to play a game that requires that access, and you think it shouldn't, contact the developer and tell them so.
The firewall would only be used by a few people who both pretend to be security-conscious and also install any app that suits their fancy. Yes, it's work to install the firewall that requires root access. Suck it up and just do it, if you want that feature. Don't saddle the rest of us with it.
Would that be possible for instance when enabling Mock locations? Or would this need some driver or kernel hacking?
There is a way, which I employ to great success: don't install the app.
The SD card is a real worry, but I thought that apps are Sandboxed in a way - they might only see the files they created themselves? I would have to check - otherwise it would of course be completely broken.
First - the windows firewall which in no time involved into one button [ALLOW] because millions of stupid users were bombarded customer support.
Lets try to establish a privilege separation everywhere, so all users will work as administrators. Lets make code bloated and slow, only because it is a proper way of doing security.
btw, do you know, which is best security solution for Windows? The low-level full restore from a copy of just installed system form the second hard drive. Most of public PC providers are using this strategy.
So, the answer is fast, easy and idiot-prof re-flash procedure.
You can use something as a storage of critical data, or as a runner for some garbage. Even at Microsoft they don't browse porn-sites from their servers.