Android Security Mechanism Analysis

The Android system is developed based on the Linux kernel. Therefore, the android system not only retains and inherits the security mechanism of the Linux operating system, in addition, its system architecture has unique security features at all levels [2].

1. Linux kernel layer security mechanism

The android Linux kernel includes the mandatory access control mechanism and autonomous access control mechanism. The forced access control mechanism is implemented by the Linux security module. For some reason, Google did not compile LSM into the android kernel. The autonomous access control mechanism is usually implemented by File Access Control. The permission control of the Linux file system is implemented by user, group, other and read (R), write (w), and execute (X). In this way, each file has three basic permission sets, which allow, restrict, and deny access by users, user groups, and other users. Generally, only users whose uid is "system" or "root" have the permission to access the Android system file, and applications can only access the corresponding file by applying for the android permission, therefore, Android uses the autonomous access control mechanism of kernel-layer Linux and the Dalvik Virtual Machine in runtime to implement the "sandbox" mechanism of Android.

2. Android "sandbox" Mechanism

Android sandbox is essentially designed to isolate different applications and processes. By default, applications do not have the permission to access system resources or other application resources. Each app and system process is assigned a unique and fixed user ID, which corresponds to the UID of the kernel-layer process. Each app runs in its own Dalvik Virtual Machine and has its own address space and resources. Processes running on the Dalvik virtual machine must exist based on the kernel-layer Linux process. Therefore, Android uses the Dalvik Virtual Machine and Linux File Access control to implement the sandbox mechanism, if any application wants to access system resources or other application resources, it must declare permissions or share uid in its own manifest [23] file.

3. Permission check mechanism for Android

Android is a "permission separation" system. Any application is using limited resources (such as network, phone, SMS, Bluetooth, address book, and sdcard) of Android) before that, you must submit an application to the Android system in the form of an XML file. The application can use the corresponding resources only after the Android system approves the application, permissions are mapped to Java APIs.

When an android application has the corresponding permissions, it can call the API to complete the corresponding functions. An API call can be divided into three steps [3]: first, the application will call the API in the public library after obtaining the corresponding permissions. Second, A public API calls an API called the API proxy (RPC stub). Third, rpcstub passes the request to the system service in the form of IPC binding, and the system service process completes the specific functions, permission check occurs precisely in system services and system processes. Permission check includes not only static checks during installation, but also dynamic checks during app running. Dynamic Check means that the system service or system component called by the app during operation must undergo authorization check. Dynamic check does not occur in the app itself, but in the process of system services or system components. Before Android, the permission check mechanism of android can be bypassed because of a vulnerability in the permission check mechanism, that is, the caller does not need to have the relevant permissions of the caller, in android4.0, the function "checkuidpermission" is used not only to determine whether the permission should be granted to the corresponding process, but also the function "checkcallingpermission" is used to check whether the caller has the corresponding permission. Therefore, the android permission mechanism cannot be bypassed, but the android permission mechanism has some defects that cannot be ignored. The details are as follows:

1. Once an application is granted the permission, the permission will be valid during the life of the application, and the user cannot be deprived of the permission;

Second, the permission mechanism lacks the flexibility to either approve all permissions required by the application or reject the installation of the application;

Third, the permission mechanism is not secure enough to prevent malware from directly calling the C library through JNI technology to obtain system services.

4. Android digital signature mechanism

All applications installed on the Android system must have a digital certificate [4], which identifies the trust relationship between the application author and the application. Android does not install an application without a digital certificate. If the protection level of a permission is signature, the Android system will authorize the application only when the digital signature used by the application is the same as the digital signature used by the application that declares the permission. If the protection level of a permission is signatureorsystem, the android system grants the permission to applications with the same digital signature or android package class.