Does Android have sufficient app sandboxing?

Question

In a previous question in InfoSec, I asked about how to determine the safety of a sideloaded Android app that requires root permissions.

Now I would like to ask a related, but different question: Is it important to check the safety of an Android app that does not require root permissions and will not have data access?

If data access is disabled for the app (via a firewall with root permissions), does it even matter if the app is "bad" in some way? You can use AppOps or XPrivacy to prevent access to the contacts and calendar and the ability to make/receive phone calls or SMS/MMS. So what harm can an app that does not have data access (and has its permissions restricted by AppOps or XPrivacy) actually do?

Another way of asking this question is: Does Android KitKat and later have sufficient default sandboxing to prevent malware from doing any harm (assuming you can block data access to/from the app via a firewall and use something like AppOps/XPrivacy to block permissions to contacts, calendar, phone calls, and SMS/MMS)?

Answer 1

Each version of Android is incrementally stronger on this front than the previous, and Lolipop certainly pushes application sandboxing a step further than Kitkat, particularly with respect to inter-app isolation.

Third-party "firewall" apps on Android are probably a bit over-hyped, and the level of protection they can offer without rooting is in my opinion a bit questionable. Android does offer some level of device control via the Device Administration API, but it's largly policy stuff, not fine-grain control over app internals.

If your device is rooted, then all bets are pretty much off, and you're on your own. Sandboxing can no longer reasonably be enforced, and it's up to you to manually control execution. Good luck.

For non-rooted devices, app permissions are controlled by the permission set granted at installation. And that permission set is enforced. If an app is malicious and you granted it permission to send SMS messages, then it will be able to maliciously send SMS messages. If it wasn't granted that permission, then it cannot do so.

AppOps allowed these permissions to be updated at runtime, but according to a developer wasn't meant to be a supported feature for general users. The reason is that it breaks stuff. And a feature that breaks everything is, sorta by definition, not supported.

This isn't the end of the story, though. The permissions model is something that the Android team is reportedly paying lots of attention to. They need a solution that (A) doesn't break all the apps, (b) gives the user meaningful control, and (c) is usable by customers with the technical skill set of a gerbil. This isn't nearly as numbingly simple as it sounds, but expect continued attention and progress on this front in the future.

Answer 2

Does Android KitKat and later have sufficient default sandboxing to prevent malware from doing any harm

How long is a piece of string? Ensuring confidentiality isn't the only goal of information security, if the App was to run a background service that constantly consumed significant CPU with the goal of draining your battery would that be a threat?

Is it important to check the safety of an Android app that does not require root permissions and will not have data access?

Beyond the privileges afforded to Apps by default, what specific resources an App may or may not be a threat to depends largely on how the Android permissions system is applied. Bare in mind that the titles and descriptions of Android permissions do not always fully or unambiguously convey what access it grants.

For example, I think the current Play Store permissions dialogue displays something like "Uses one or more of: SMS, MMS. Charges may apply." for access to SMS, which does not necessarily give the impression that it can read SMS's.

Therefore even if you were to read and selectively apply every permission individually, you might still end up affording some access that you didn't anticipate.

Beyond that, Android Apps have access to a significant number of permissions by default or without explicit approval. For example I believe the Play Store does not currently display internet access on its permissions acceptance dialogue.

Both of these examples are specific to Apps installed via the Play Store, but I'm sure there's examples that don't depend on the Play Store. Also, even if you check the permissions after installing an App via the Play Store and revoke certain ones, there is still a window where the App could be a threat.

If data access is disabled for the app (via a firewall)

Finally, I wouldn't discount side channel attacks. A malicious App can use IPC to pass information to another App which then exposes it to the Internet. The simplest example would be the App constructing an Intent to open a URL in a browser, and that URL could of course contain sensitive information. Unfortunately the Android App selector dialogue (where you'd select your browser) does not show you the URL to check for sensitive information before it's opened. At that stage it might be too late.

TLDR; Android does have strong sand-boxing compared to a traditional desktop OS, but that isn't an excuse to be careless. You should still consider 3rd party software to be a threat and evaluate it accordingly, relying on the sand-box to be an extra layer of security in case your other controls fail.