Android Permissions Control

One fact which I had written about before, was that Android differs from Linux, in that under Android, every installed app has its own username. Also, because different users installed a different set of apps in different order, the UID – an actual number – for any given username will be different from one device to the next. And then I also wrote, that a username belonging to a group or not so, can be used to manage access control, just like under Linux.

There is a reason for which things are not so simple with Android. Most Android apps are written in a language named “Dalvik”, the source code of which has syntax identical to “Java”, and which must be compiled into “Bytecode”. The bytecode in turn runs on a bytecode interpreter, which is also referred to as a Virtual Machine.

The reason for which this affects permissions, is because as far as the kernel can see, this VM itself runs under one username. This is similar to how a Java VM would run under one username. And so a much more complex security model is put in place by the VM itself, because presumably this VM’s username has far-reaching capabilities on the device.

The actual use of groups to control access under Android is simpler, and applies at first glance to processes which have been compiled with the ‘NDK’ – with the “Native Development Kit” – and which therefore run directly, say from C++ source code.

Further, the Dalvik VM is capable of reading the permissions of actual files, and is capable of applying its own security model, in a way that takes the permission bits into account, that have been assigned to the files by the Linux kernel. So for most purposes, the security model on the VM is more important than the actual permission bits, as assigned and implemented by the kernel, because most Android source code is effectively written in a Java-like language.

Dirk

 

NFC Tasks can use Tasker now.

Now that I do have “Tasker” installed, I have uninstalled “NFC Tasks” and reinstalled it again. And the result is, that Actions programmed by “NFC Tools” finally have the permissions required to run Tasker Tasks. When previewing Tasks, NFC Tools uses NFC Tasks as a conduit.

I recently commented about this here, at a time when NFC Tools was displaying ‘Not Enough Permissions’ when told to preview Tasks that contained Tasker Tasks as Actions.

Dirk

 

Android App Permissions Dialog

Most Android users are at least vaguely aware, that every time we install or update an app, we’re shown a dialog with a list of permissions the app is requesting on our mobile device. We can either Allow or Deny this request.

What people should be aware of as well, is that by default, Android did not allow us to Accept or Decline each permission on its own. We were shown the whole list, and would then have to either Accept or Decline the entire list, and in the latter case, the app would not install, or the update would not take place.

This was a rather powerless feature, because when we declined an update, Google Play would just come back within short order, and offer the same update again. Also, there was no way to opt out of updating for one specific app. So we would then either be obliged to accept the update at a later time, or to uninstall the app.

This was the status-quo up to and including “Android Lollipop”. The Android version that came after Lollipop, and which is the current version, is called “Marshmallow”. And the main, key improvement which Marshmallow offers, is control by the user, for each individual permission the app is asking for. With Marshmallow, the user is no longer obliged either to accept the entire list of permissions or to reject it. He can grant or deny any specific permission, and then still install the update, which gets rid of the messages for that update.

One reason fw this is important, is the possibility of a “Privilege Escalation”, which is also a known form of cyber-attack. Privilege Escalation means, that an already-installed app can ask for progressively more permissions during each update, which users often don’t pay strict attention to, so that after several updates, the app has a dangerous collection of them on our device.

Granted, most of the time the apps need a large number of permissions for innocuous purposes, or maybe because they’re just not programmed well enough, to work without those. But the potential exists for too liberal a set of permissions eventually to compromise our privacy online, or even our online security.

This is why, regardless of whether we have Marshmallow or not, we should in fact be examining the requested permissions each time, before we simply grant them.

Having said that, I don’t have Android Marshmallow yet. This is secondhand information, from a friend of mine who is in the know, and who has Marshmallow on at least one of his devices.

Dirk