First learn the basics:
Android is a layered operating system, which consists of four layers, namely Linux kernel, native user space, Android framework and application.
The core security principle of Android is that applications should not harm operating system resources, users and other applications.
1.Linux kernel layer
The Linux kernel is responsible for configuring the application sandbox and standardizing some permissions.
Configure an application sandbox for each application, and each application runs in its own sandbox. During the installation process, each software package will be assigned a unique UID (User Identifier) and GID (Group Identifier), which will change during the application life cycle of the device. So every application has a corresponding Linux user. The user name follows the app_x format, and the user's UID is equal to process. First _ Application _ UID+X. Because each application has its own UID and GID, the Linux kernel forces the application to execute in its own isolated address space, and the unique UID and GID of the application are used by the Linux kernel to realize the fair separation of direct resources of different applications, and each application is verified based on the Linux optional access control model (DAC). In addition, applications signed with the same certificate can share data with each other, have the same UID, and even run in the same process. We can use adb command adb shell ps to view some information of all processes in the mobile phone.
By assigning Linux users and group owners to components that implement this function, applications are restricted from accessing certain system functions. Use file system permissions to access files and device drivers, and restrict processes from accessing certain functions of the device. The /dev/cam device driver belongs to the root owner and the camera owner group, which means that only processes running as root or included in the camera group can use this driver, which is what we call the camera function. If you agree to use the camera function in the installed application, the application will be assigned a camera Linux group GID, which indicates that the application can read information from the /dev/cam device driver. The mapping between these rights labels and the corresponding groups is defined in the file framework/base/data/etc/platform.xml. ..
2. Local user space layer
Build file system structure and file permissions
The boot sequence of Android devices can be divided into the following steps: bootrom-bootloader-Linux kernel -init.
When the user turns on the mobile phone, the CPU of the device has not been initialized. In this case, the processor executes the command from the hard-wired address, which points to a piece of code in the write-protected memory of the CPU where the boot rom is located. The main purpose of these codes is to attach to the media where the boot loader is located. After the detection is completed, the Boot ROM loads the Boot Loader into the memory, starts to execute the loading code of the Boot Loader, and is responsible for establishing external RAM, file system and network support. After that, Linux starts to load, the kernel initialization environment runs C code, starts to load drivers, mounts file systems, and runs user space processes. In Android, the first user process is init, which starts with root privilege (UID=0) and is the ancestor of all processes. Init has a configuration file init.rc, in which some events are predefined. The init runtime will be executed according to its predefined events, mainly responsible for creating the basic file structure, setting kernel parameters, starting the ueventd daemon, starting the ServiceManager and starting the Zygote process. The first daemon is the ueventd daemon, which mainly sets the owners and permissions of different devices. ServiceManager acts as an index of all services in Android. The zygote is the ancestor of all processes, and all our applications are made of zygote forks.
/system, /data and /cache are the core directories of the Android file system, and they are all installed to predefined points by init programs. The /system partition contains the whole Android system except the Linux kernel, and this folder contains subdirectories /system/bin and system/lib, which correspondingly contains the local executable files of the kernel, * * * shared library and all system applications pre-built by the system image, and the image is installed in a read-only way, so the contents of this partition cannot be changed at runtime. Since /system is mounted read-only and cannot be used to store data, another separate partition /data is responsible for storing user data or time-varying information. The /cache partition is responsible for storing frequently accessed data and application components. Default permissions for these folders must be defined at compile time.
3.Android framework layer
Application framework-level security is implemented by IPC reference monitor.
Because applications run in isolated sandboxes through different processes with different Linux identities, an IPC framework is needed to manage data and signal exchange between different processes. In Android, the communication between processes is mainly realized by Binder, which is a special framework. It has been redeveloped in Android to support inter-process communication, and it provides the functions needed to manage all types of inter-process communication in Android operating system.
In Android, every key function (service method) of a service is called special label protection of permissions. In other words, before executing such a function, it will check whether the Diaohong process has been assigned permissions. If you have permission, you are allowed to call, otherwise a security check exception will be thrown. We must write the corresponding permissions into AndroidManifest.xml, and the permissions listed as dangerous after 6.0 need to be dynamically applied in the code. There are four permission levels in Android, namely Normal, Dangerous, Signature and signatureOrSystem. By default, third-party application developers cannot access features protected by system permissions at the level of signture and signatureOrSystem. Therefore, applications that need to use these rights protection levels must be signed with the same platform certificate. However, only the builder of the operating system can access the private key of the certificate. We can understand why the Huawei application market of Huawei mobile phones can install applications silently, while AppBao can only jump to the application installation page. At the same time, the Android framework provides a class PackageManagerService, which is responsible for the application management in Android. An important function of this service is permission management, which is responsible for checking whether the application installation and upgrade conform to the permission model.
4. Application layer
These four components and application permissions are declared in AndroidManifest.
Android apps are distributed in the form of Android packages (. Apk) file. A package consists of Dalvik/ART executable file, resource file, manifest file and local library, and is signed by the application developer with a self-signed certificate. Each application consists of several components of four component types: activities, services, BoardcastReciver and content providers. Every component (except BoardcastReciver) needs to be declared in AndroidManifest.xml, and BoardCastReciver can also be declared dynamically in the code. Components communicate through Intent, which is a special communication means based on Binder framework.
Applications can also use custom permissions to protect access to the application components, similar to one of the system permissions. That is, if the application 1 wants to protect its access to A 1, it needs to declare a permission label P 1. At this point, if application 2 wants to access C 1, it must declare the P 1 permission in AndroidManfest.xml