3 ms·
> Most focus on multi-user security, which still has its uses, but they fail to focus on application isolation. Applications should be installable by anyone and
by rogerbinns 14y ago
> Most focus on multi-user security, which still has its uses, but they fail to focus on application isolation. Applications should be installable by anyone and isolated completely from other apps unless specifically granted permission by a user/administrator.
Incidentally this is exactly what Android does. They provide the isolation by creating a new user account for each app and by default apps get no permissions. The permissions you accept at install time then allow extra access. (Behind the scenes there are also mechanisms to provide security permissions across processes so that a second process doing work on behalf of your process is limited to your processes permissions.) Multiple problems have happened.
The initial default permissions in Android 1.0 were a little too permissive and for example allowed reading from the sdcard. While that seemed harmless at the time, it was in retrospect a bad choice.
There is no hard validity checker. For example if an application ignores the API call to find the location of the sdcard and instead just uses /sdcard then no one would know. This means that it is very easy for apps to not comply with best practises to be available, the developers don't even know it, and the platform has problems if they want to fix the issues due to the large installed base. (If Angry Birds stopped working because they hard coded things instead of using APIs would Android or Rovio get blamed?)
Android also made a decision that you either accept an app and its permissions, or not install it. There are good arguments both ways of only allowing them as a whole or being able to disable some permissions. But the net effect is that many apps have more permissions than they do use, and have to declare them if there is any chance they could be used. Users can choose to not install apps with too many permissions, but you can't leave a review explaining that. I see a lot more pushback over permissions in app store reviews these days, but the many years of prior practise mean far too many apps have too many permissions. (BlackBerry had this scheme where for each permission you could set it to grant, deny or ask on each use. For the tech crowd it is great, but for someone who just wants to play a game it is annoying and probably not helpful.)
The permissions themselves are not sufficiently granular - for example "Internet" is on or off. An email app contacting my email server is great, but contacting a command and control server in another country is a huge problem. Of course some sort of per connection prompting could happen, but isn't really practical for the vast majority of users.
Commercial issues have a been a problem too. For example the Google Play Store is not available in China (and many other countries). Consequently users have to use a different store, and some have different incentives as app stores are not lucrative.
Finally we have the "fragmentation" issue. Google did not implement Android in such a way that the majority of core could be upgraded by Google. Consequently you end up with full stack releases which depend on manufacturers and carriers deploying after they have already sold a device - something they have no incentive to do. This would need to be solved by aligning incentives, and is hard.
TLDR: the hard stuff is hard. Application isolation is already done by all the mobile operating systems. It is the nitty gritty details beyond that that need solving.
- api 14y agoInteresting. Wasn't familiar with the deep details, though I knew Android did something like this. I don't like the user-account-per-app paradigm. It seems like an ugly abuse of multi-user access control to compensate for the missing app isolation piece. I agree that it's a hard problem.
- kevb 14y agoIf we ignore the word "user" it feels (and is) a lot less like abuse and actually fits very well. Linux has a proven and secure method of isolating access, and on linux servers and linux on the desktop this is used by different users to protect them from each other (intentional or accidental). In Android it's more important to isolate access between apps, again protecting them from each other, intentional or accidental. Even for well intentioned apps, like Chrome or Flash, that kind of secure isolation is extremely desirable, and I don't see much value in a custom built sandbox over reusing the isolation that's already proven.
- 0xABADC0DA 14y ago> [Android] provide the isolation by creating a new user account for each app and by default apps get no permissions. That's ok, but if the app ever manages to get more permissions then it may be able to keep them (set-uid shell for example, or keeping a socket open past being permitted to use the network, or holding some token, etc). I don't know how much of that you can do with Android per se, but in general it's not enough to use programmatic permissions like that. Another factor necessary for security is non-interceptable input. This is part of why iPhone has a physical button for going to the home screen, so that it is not possible to fake a home screen. With a software button some app could go fullscreen and present a bogus button and then use a fake home screen to trick users (it wouldn't be easy but possible). So a huge missing factor on desktop OSes is missing hardware support for input to the OS. Windows kind of has this with ctrl-alt-del, where you can log in without any possible fake login screen. Instead of "caculator" or "play/pause" there should be special buttons that only input to the OS and are not readable by applications. For instance instead of a Gnome dialog box asking for your password to approve some change the user should press the "secure ok" key on the keyboard.