App Isolation, Usacurity
Usability + Security = Usacurity
I’ve been thinking a lot about app isolation/sandboxing lately. I really haven’t seen any operating system get it right. Maybe OLPC’s Sugar comes closest. And since this is starting to get serious business for several projects near and dear to me (GNOME, Ubuntu, Firefox OS) I want to share my thoughts on this.
What concerns me is user interfaces like Google’s Play for Android. When you install an app you get presented with a list of permissions this app requires. But as anyone in computing knows – if you put a bullet point list with an OK button at the bottom between the user and the user’s desire – then that OK button is going to be clicked very fast.
Hawt New Wallpapers App
This app can:
- Access and control your webcam
- Read your address book
- Access your online accounts
- Modify your system settings
- Record audio
- Draw in the windows of other applications
- Prevent the device from entering standby
- Change your wallpaper
Cancel OK
So there is a small “aware” subculture that actually read these permissions. But an extremely small subset of that culture have the faintest idea what the permissions even mean!
At the heart of the problem is the fact that it’s actually an expert task to assess which app permissions are “OK”. Are the permissions for Hawt New Wallpapers App “OK”? (hint: no).
The operating system should take you by the hand here, to help you make this decision.
The Idea: A Guided Choice
So what can the friendly OS developer do about this? A great deal I think. The OS have quite a bit of structured metadata about the app available to help here.
For instance, most application stores these days have some form of categorization of the content. An app can be a Game, and several different specific sub categories of Game; Puzzler, Platformer, etc. Most open source platforms use the XDG categories which is quite rich in this regard.
Now, simply cross ref the app category against a white listed set of permissions. A game that can play back audio and access the internet is probably not worth nagging the user about. However a game that can access your webcam or your address book, or spawn daemons that run after the app has been shut down, should be considered out of the ordinary.
Based on this categorization/permission cross ref the OS can compute a threat score, which could be shown to the user via green, yellow, and red badges on the app or something. And a threat score above X should probably simply be entirely disallowed in the store.
The threat score can be augmented in many ways – fx. certain combinations of permissions can also be considered dangerous. Like both being able to access your webcam and having full access to the internet.
The UI need not show anything else than this threat level badge by default, with the option to expand and explanation of why the threat-o-meter wound up the way you see.
Hawt New Wallpapers App
<blink>☠ This app has outrageous permissions. Only install if you blindly trust the developer</blink>
Cancel OK
There’s a Back Door!
Basing the threat score on the app categorization of course opens the door up to simply changing your app’s category from Game to SystemTool.
But this will cost the app developer about 99% of the install base, if the app store’s user experience is in any way centered around the categories. So yes; there is a theoretical back door. But with consideration in the store’s UI I believe you can protect 99% of the user base adequately.
February 24th, 2013 at 14:43
Hi! I also thought about this issue a long time ago.[1] I develop a cross-distro Linux-App-Installer called Listaller, which uses the “thread score” idea already.
It basically looks at the (valid) signature of a package, at who signed it, at stuff the application will install (basically if it installs stuff in custom places) and some other things. From all these variables, an overall security score is calculated (green, yellow, red, “dark red”). System administrators can set a minimum security level. If an app is below that, the tools will refuse to install this application, actively preventing dangerous actions. If users want to install it anyway, they have to adjust the security level. By requiring an action like this, users will *definitely* think about what they are doing and not just click okay. ^^
Taking XDG categories into account to show an easy-to-understand message if an application uses permissions which don’t quite fit for it’s category is a great idea! (although defining these permissions will be difficult)
What is really needed at time is a sandbox which allows users to define clearly which fatures a given application can access. Apps should be able to request permissions at install-time, but users should be able to reduce the application’s permissions via a simple dialog. If an application needs a certain feature, the system should ask the user to allow it when the app makes use of it the first time (“Application X wants to access your microphone. Do you want to allow this (Y/N)”). With an approach like this, apps can be run with minimal permissions, and only necessary permissions can be unlocked. (e.g. you can prevent your PDF reader to go online)
[1]: http://blog.tenstral.net/2011/06/security-and-software-installations.html (old and incomplete ideas, but it was the basis for the “app-security traffic-light” system)
February 24th, 2013 at 16:08
> certain combinations of permissions can also be considered dangerous. Like both being able to access your webcam and having full access to the internet.
Or maybe it’s a chat application?
February 24th, 2013 at 16:09
Are you aware of Qubes?
February 24th, 2013 at 17:19
The problem is false-positives. Suppose I wrote a simple game, but wanted to add some fun personalization and socialization to it. So when you create your “character”, you will have the option of taking a picture of yourself and having that picture converted to a cartoon-like face. Fun! But now my game has added “Access the webcam” threat points. Then I want to tell you if any of your friends are also playing, so you can collaborate. Fun! But now my game has added “Access your Addressbook” threat points. Want to submit your scores to a central scoreboard? Bam, “Access the internet” threat points. Share stuff via Facebook or Twitter? “Access your online accounts” threat points.
Yes, those are all optional features, they aren’t a large or necessary part of my game. But they are the feaures that make my Scrabble clone different from the other 200 Scrabble clones in the app store. But now my differentiating features are going to make the OS scare the user away from my app.
February 24th, 2013 at 19:50
@Matthias: The prompt-the-user-for-privilege escalation was done on many of the old mobile OSes (hello Symbian). I kinda liked the idea – but it’s pretty tricky to manage though. When are the privs dropped? Can the app somehow linger in the background hogging onto the rpivs? Etc. The problem is that statefullness here introduces a big complexity – which again makes it insecure. That said – I like the idea if it was possible to implement in a very clear cut way.
@bochecha: The combination of permissions could be weighed by the app category – making it less of a penalty for chat apps. Still – a chat app is a big security concern no matter how you cut it.
@smb: No?
@Michael:Access to web cam should happen via the “web cam app” or normal camera app. You’d request a picture from the camera, then the relevant app does the job on your behalf, in its own security context, and somehow deliver the payload back to your game. Similar for access to address book. All in all 0 threat points for your game
It’s all about designing the OS from the ground up to be secure for the user.
February 24th, 2013 at 20:09
The situation that Michael describes appears to describe many of the seemingly unnecessary permissions in many apps that I have seen.
Some developers include apologetic descriptions of what the permissions are used for – eg. https://play.google.com/store/apps/details?id=bbc.iplayer.android&hl=en .
I think the answer might lie in making more use of the small subset of users who actually care about permissions to help with the much larger subset of users who will blindly click ‘Install’ – effectively a kind of moderation system, though like any moderation system it could be vulnerable to gaming.
February 24th, 2013 at 20:14
Here is another good example of the false positives that Michael mentioned – https://play.google.com/store/apps/details?id=air.uk.co.bbc.android.mediaplayer
In this case the app gets access to your phone’s unique ID and state simply because it wants to avoid disrupting the user during phone calls. This permission can also be required due to other unfortunate technicalities – http://android.stackexchange.com/questions/605/why-do-so-many-applications-require-permission-to-read-the-phone-state-and-ident
February 24th, 2013 at 20:34
Robert: From these examples it seems more like either one, or both, of: 1) The app is a square peg being rammed into an Android-formed hole, 2) The developers have misunderstood a crucial API (which is of course not the dev’s fault, but Android’s).
But as it stands apps get off with grotesque permissions, because it doesn’t put a dent in the sales. But if you start getting a red flag I am pretty sure the devs can figure out the Right Way (TM) if they spend a day or two more in the hack-room
February 25th, 2013 at 10:30
I’ve always thought that the OS should give the user the option of providing faked data to the application, such as a fixed location, or always claiming that there’s no internet access available.
February 25th, 2013 at 10:32
@Alexander: I think this would be a nice feature – but it can be trickier then it would seem to get Just Right. More importantly I regard it as an expert feature. I bet you less than 1% of users (for a mainstream OS) would use it.
February 25th, 2013 at 15:57
I liked it how in OLPC’s sandbox some permissions weren’t compatible with each other. For example, a downloaded application could access all the user data OR open sockets. But all applications would be able to access their own storage and use their own kind of Telepathy tubes.
February 25th, 2013 at 20:09
@Tomeu: Yep, that’s also what I liked about OLPC/Bitfrost. There was no choice to make for the user. The system is just secure. The app developer have to make the hard choices – the only one really qualified to make it in the first place!
February 26th, 2013 at 09:16
None of the features or problems you talk is related to operating system.
The relating stuff what OS does is to protect process and its threads from other processes and threads, allocate protected memory to them, give network access over TCP/IP (etc), offer easy way to write and read data from storage devices (FS) and finally handle all I/O.
In OLPC system and Ubuntu (etc) the operating system is Linux. The IT-world one of biggest problems have been caused when someone gets idea to add features to OS what does not belong there.
All processes are already isolated but OS can not rule out anything if software developers does allow their software to interact with others willingly.
The problem is way up from the OS and exist in software platforms and libraries.
But we can always enforce even more the software system like what SELinux is about, you make rules what every file and process/thread can do and no software developer can override those if user does not want to.
February 26th, 2013 at 10:31
MK: If I meant “kernel” or “Linux” I would have said that. The “OS” I refer to in this post is intended to mean kernel+lowlevel userspace+toplevel ui. The whole package. Sorry if that was unclear.
The whole point is that security can not be implented by just focusing on one specific layer of the software stack. It must be considered as a whole in order to provide the best user experience and security.
So concretely I am thinking about Linux with some form of MAC, a set of policies and tools on how developers interact with the MAC, together with a definition of how software is installed and run. This would define what we could call an “application model”. Platform libs must be developed with the application model in mind, and central apps should take the application model into account as well (not that they’d have a choice under a strict MAC).