Android security model
Android is a multi-process system, in which each application (and parts of the system) runs in its own process. Most security between applications and the system is enforced at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. Additional finer-grained security features are provided through a “permission” mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data. (Android Developers Guide-Security, 11/2010)
The Android security model is primarily based on a sandbox and permission mechanism. Each application is running in a specific Dalvik virtual machine with a unique user ID assigned to it, which means the application code runs in isolation from the code of all others applications. As a consequence, one application has not granted access to other applications’ files. (1)
Android application has been signed with a certificate with a private key Know the owner of the application is unique. This allows the author of The application will be identified if needed. When an application is installed in The phone is assigned a user ID, thus avoiding it from affecting it Other applications by creating a sandbox for it. This user ID is permanent on which devices and applications with the same user ID are allowed to run in a single process. This is a way to ensure that a malicious application has Can not access / compromise the data of the genuine application.
It is mandatory for an application to list all the resources it will Access during installation. Terms are required of an application, in The installation process should be user-based or interactive Check with the signature of the application.
The purpose of a permission is to protect the privacy of an Android user. Android apps must request permission to access sensitive user data (such as contacts and SMS), as well as certain system features (such as camera and internet). Depending on the feature, the system might grant the permission automatically or might prompt the user to approve the request. (2)
Permissions are divided into several protection levels. The protection level affects whether runtime permission requests are required. There are three protection levels that affect third-party apps: normal, signature, and dangerous permissions.
Normal permissions cover areas where your app needs to access data or resources outside the app’s sandbox, but where there’s very little risk to the user’s privacy or the operation of other apps. For example, permission to set the time zone is a normal permission. If an app declares in its manifest that it needs a normal permission, the system automatically grants the app that permission at install time. The system doesn’t prompt the user to grant normal permissions, and users cannot revoke these permissions.
Signature permissions: The system grants these app permissions at install time, but only when the app that attempts to use a permission is signed by the same certificate as the app that defines the permission.
Dangerous permissions cover areas where the app wants data or resources that involve the user’s private information, or could potentially affect the user’s stored data or the operation of other apps. For example, the ability to read the user’s contacts is a dangerous permission. If an app declares that it needs a dangerous permission, the user has to explicitly grant the permission to the app. Until the user approves the permission, your app cannot provide functionality that depends on that permission. To use a dangerous permission, your app must prompt the user to grant permission at runtime. For more details about how the user is prompted, see Request prompt for dangerous permission.
However, the Android operating system also revealed some of its faults for the user may be attacked and stolen personal information.
Some security vulnerabilities on Android:
– Leaking Information to Logs: Android provides centralized logging via the Log API, which can displayed with the “logcat” command. While logcat is a debugging tool, applications with the READ_LOGS permission can read these log messages. The Android documentation for this permission indicates that “the logs can contain slightly private information about what is happening on the device, but should never contain the user’s private information.”
– SDcard Use: Any application that has access to read or write data on the SDcard can read or write any other application’s data on the SDcard.
– Unprotected Broadcast Receivers: Applications use broadcast receiver components to receive intent messages. Broadcast receivers define “intent filters” to subscribe to specific event types are public. If the receiver is not protected by a permission, a malicious application can forge messages.
– Intent Injection Attacks: Intent messages are also used to start activity and service components. An intent injection attack occurs if the in-tent address is derived from untrusted input.
– Wifi Sniffing: This may disrupt the data being transmitted from A device like many web sites and applications does not have security measures strict security. The application does not encrypt the data and therefore it can be Blocked by a listener on unsafe lines.
Security issues for smartphones running on the system Android operating system is the user does not have the knowledge or careless installation of the software Malicious or other attacks such as phishing. Important security issues The second is that some legitimate applications that have vulnerabilities can be exploited.
(1): Joany Boutet (2010). Malicious Android Applications: Risks and Exploitation.