Let’s begin with answering one of the title initial questions: “Should I care about application permissions?” Our answer is YES, and below we will answer why.
To help you get a clearer picture, let’s answer some lingering questions, starting with: What actually are “permissions”?
As a user of any modern smartphone, you may have noticed that each time you run, install, or update an application, your phone (or tablet), depending on its OS, asks certain questions about whether or not to allow access to specific parts of the system. These are actually how permissions work.
Let’s dive a little deeper and compare how each mobile operating system handles and manages those app requests. Since their permission requests are an important part of the security system, it’s worth examining who does it well and who doesn’t. We’ve looked into iOS, Android, and Windows Phone/Windows 10. There are many similarities in all permission mechanisms, but differences are still apparent.
Android Permission Mechanisms
Starting from Android 6.0, users now grant permissions to applications while they are running, not when they install the app like in previous Android versions. This way, the application installation process feels more seamless since there is now no need to grant permissions during installation or while the app is updating. And thanks to a recent update, new capabilities give the user much more control over the app’s permissions. For example, a user could now choose to give a geolocation app access to the camera but not to the Contact List. Furthermore, that user can now revoke access to any previously granted permission by going to the Settings screen of the desired application.
Android Permissions Mechanism
Now let’s look what’s under the hood of Android’s permission mechanisms:
Generally, there are two types of system permissions: normal and dangerous.
Normal ones do not directly engage with user’s privacy. If your app lists a normal permission in its manifest, the system will grant the permission automatically.
Dangerous permissions can give the app access to the user’s confidential data. If you list a dangerous permission in your app manifest, the user has to give manual approval to your app.
And since Android is based on Linux kernel, it uses two of its permission mechanisms: sandboxing and access control based on read-write-execute permission tuple.
Each Android app is hosted in an ART (Dalvik in earlier Android versions) virtual machine. The trick is that each application is running in so-called “sandbox,” which means that they’re isolated from each other in their own virtual machines. Linux kernel manages this process. Each virtual machine and, as a consequence, every application represents a single Linux kernel process. So the application must strictly declare which permissions it needs, and if these permissions are something that sandbox can’t provide, the user will be asked for consent once the app needs this permission (at install time on all Android versions prior to 6).
The second mechanism is also transited from Linux. Data and other app-related information are isolated from other apps using a “read, write, and execute” method, so to access data from another application, it must first be exposed via a content provider accessed by the message bus (a library that provides one-to-one communication between any two applications).
Tip for developers: Many Android users are using their freedom to modify device firmware, so they acquire access to run programs using privileged user ‘root,’ so to protect your application from hacking, we advise you add an additional level of security.
iOS Permissions Mechanisms
During the years of iOS evolution, Apple has developed an ideal permission system. The operating system lets the user decide whether an app accesses everything from the device’s sensors or only specific parts of it. The first-time user runs the app, and if the app wants to use some part of the system that can expose any personal data, it must have permission from the user. Users can see which parts of the system apps have access to and manage them later almost the same way Android does it.
iOS Permissions Mechanism
iOS is developed that way, so all downloaded apps run as the non-privileged user called ‘mobile.’ Only a few of the most important system processes run as the privileged user called ‘root.’ Thanks to this method, no programs are able to change internal configuration. All apps that are downloaded from the App Store or elsewhere are isolated from each other using a ‘sandboxing’ mechanism. There are various sandboxing techniques, but iOS implemented it as a policy module in the TrustedBSD mandatory access control framework. Each application has its own PLIST (property list) file in XML format that declares which special capabilities or security permissions in iOS the app can ask access to. Once the user launches the app, iOS determines its sandbox policy according to its PLIST file. Despite that even some built-in apps are limited to ‘mobile’ user, they still may have lower-level access via reserved entitlements.
As for keychain items, an app can access only its own items, such as passwords, keys, certificates, etc.
Despite that generally iOS and Android mechanisms appear the same, there are many differences. For example, Android individually regulates each installed app by using the declarative permissions, while iOS applies sandbox configuration on most third-party apps, which makes them share the same broad set of privileges. As for iOS 6, there are only a few sensitive operations, such as accessing location information and the contact book and sending push notifications, that have to be explicitly acknowledged by users before they can proceed.
Tip for developers: Many iOS users are using their freedom to modify device firmware, so they acquire access to run programs using privileged user ‘root.’ To protect your application from hacking, we advise you to add additional levels of security considering this situation.Windows 10 Mobile Permissions Mechanisms
Windows Mobile Permissions System
**(Windows uses the term “capability” instead of permissions)
Due to the proprietary and closed-source nature of Windows systems, we don’t know many internal details about how permissions work on the kernel level, but we do know how to declare, manage, and classify them.
Like in any modern system, some Windows apps or games in the Windows Store are designed to take advantage of various hardware and software features on your Windows device.
Let’s take a look at real-life example, like when a camera app might need to use your phone’s GPS, or a fitness app might use your accelerometer to count your steps. In this case, in Windows 10, you can choose which apps can use a particular feature. You simply need to go to Settings > Privacy. Select the feature (for example, Camera) and select which app permissions are on or off. To see the feature permissions for an app, go to the app product page in Windows Store. If you don’t want an app to use any of the listed features, you can choose not to install it.
Windows Phone Permissions Mechanism
Messages, geolocation, camera, microphone, etc. are parts of the system that can access the user’s personal information, so they are considered as sensitive. In Windows 10, like in other two OSs that we’ve reviewed earlier, privacy settings let the user dynamically control access to sensitive resources.
But how does Windows 10 classify capability categories?
Currently, there are four categories:
● General-use capabilities that apply to most common application scenarios.
● Device capabilities that allows app to access peripheral and internal devices.
● Special-use capabilities that require a special company account.
● Restricted capabilities that are only available to Microsoft and its partners.
Like with iOS and Android, permissions for accessing sensitive resources are controlled on a per-user, per-app, per-resource basis. However, one should remember that there are cases when apps won’t have access to specific information, so apps should be ready to handle these situations accordingly. In other words, different users could set different privacy settings for the same app, and each user can give the same app different permissions on different devices. For example, there may be one set of permissions on their PC and a different set of permissions on their phone.
Conclusion
This has been the general information about mobile operating systems permissions mechanisms.
You may notice that they are looking similar as those in ‘big’ operating systems. This is because smartphones are constantly evolving, and their operating systems evolve along with them. These days, we essentially carry small personal computers in our pockets. We also hope that as a developer, you understand all the importance of these security mechanisms, and we hope that as a user, you will take those 5-10 minutes and configure all of your apps so none of your personal information will be exposed to anyone.
