In our previous post “Android Permissions a Truth unfold“, we have discussed the ways how android permissions can cause a disrupt-able amount of damage to the user data,applications and devices.Let us see how permissions take effect and are enforced in android api level,intent and content provider.
Permissions
In android to enforce permissions, various parts of the system invoke a permission validation mechanism. It helps in checking whether a given application has a specified permission or not. The permission validation mechanism is implemented as part of the “trusted system process“, and invocations of the permission validation mechanism are spread throughout the API.
It appears there is no centralized policy for checking permissions when an API is called. Rather, solution lies in the correct placement of permission validation calls. Permission checks are placed in the API implementation in the system process. When necessary, the API implementation calls the permission validation mechanism to check that the invoking application has the necessary permissions. In some cases, the API library may also redundantly check these permissions, but such checks cannot be relied upon. Android applications can bypass them by directly communicating with the system process via the RPC stubs. Permission checks therefore should not occur in the API library. Instead, the API implementation in the system process should invoke the permission validation mechanism.
A small number of permissions are enforced by Unix groups, rather than the Android permission validation mechanism. In particular, when an application is installed with the permissions enabled for use of services like INTERNET, WRITE_EXTERNAL_STORAGE, or BLUETOOTH permissions, it is assigned to a Linux group that has access to the pertinent sockets and less. Thus, the Linux kernel enforces the access control policy for these permissions. The API library (which runs with the same rights as the application) can accordingly operate directly on these sockets and less, without needing to invoke the API implementation in the system process. If a single permission is applied to a diverse set of functionality, applications that request the permission for a subset of the functionality will have unnecessary access to the rest. Android aims to prevent this by splitting functionality into multiple permissions when possible, and their approach has been shown to boost platform security.
When talking about the “Native Code“. Applications can include native code in addition to Java code, but native code is still beholden to the permission system. Attempts to open sockets or less are controlled by Linux permissions. Native code cannot communicate directly with the system API. Instead, the application must create Java wrapper methods to invoke the API on behalf of the native code. Android permissions are enforced as usual when the API calls are executed.
Content Providers
Content Providers are installed in android as standalone applications, separate from the system process and API library. They are protected with both static and dynamic permission
checks, using the same mechanisms that are available to applications to protect their own Content Providers.
Static declarations assign separate read and write permissions to a Content Provider. By default, these permissions are applied to all resources stored by the Content Provider. Restrictions can also be applied at a finer granularity by associating permissions with a path . For example, there is a scenario where a Content Provider that can stores both public and private data might want to set a default permission requirement for the whole Content Provider, but then allow unrestricted access to the public data.
Extra permission requirements can similarly be set for certain paths, making data under those paths accessible only for the calling application has the default permissions for the provider as well as the path-specific permissions. Content Providers can also enforce permissions programmatically. The Content Provider code that handles a query can explicitly call the system’s permission validation mechanism to require certain permissions. This gives the developer greater control over the granularity of the permission enforcement mechanism, allowing developer to selectively require permissions for query values or database data.
Intent
Android’s Intent system is used extensively for inter- and intra-application communication. To prevent applications from mimicking system Intents, Android restricts who may send certain Intents. All Intents are sent through the ActivityManagerService (a system service), which enforces this restriction. Two techniques are used to restrict the sending of system Intent. Some Intents can only be sent by applications with appropriate permissions. Other system Intents can only be sent by processes whose UID matches the system’s. Intents in the latter category cannot be sent by applications, regardless of what permissions they hold, because these Intents must originate from the system process. Applications may also need permissions to receive some system Intents. The OS uses the standard Android mechanism for restricting its Intent recipients. An application (in this case, the OS) may restrict who can receive an Intent by attaching a permission requirement to the Intent.