Analysis of Android security architecture and permission control mechanism

Introduction: Android is a popular open-source mobile platform in the industry. It has been widely used by many mobile phone manufacturers as mobile phone operating system platforms. Therefore, it is of great importance to study its security architecture and permission control mechanism. This article starts with the hierarchical security architecture of Android, introduces the security architecture of Android platform and its permission control mechanism in detail, covers the permission application methods of Android applications, and resolves this mechanism from the source code implementation layer.
Android hierarchical security architecture
Android is a mobile device platform. Its software hierarchy includes an operating system (OS), MiddleWare (MiddleWare), and Application ). Based on the software block diagram of Android, the software hierarchy is divided into the following layers:
● Operating system layer (OS)
● Various Libraries and Android RunTime Environments)
● Application Framework)
● Application)
The following describes the key points of Andoid software and related technologies:
(1) operating system layer (OS)
Android uses Linux2.6 as the operating system. Linux2.6 is a standard technology, and Linux is also an open operating system. Android's use of the operating system includes the core and the driver. Android's Linux core is the standard Linux2.6 kernel, and Android requires more drivers related to mobile devices. The main driver is as follows:
● Display Driver: Commonly Used Frame Buffer Drivers Based on Linux
● Flash Memory Driver)
● Camera Driver: commonly used Linux-based v4l (Video for) drivers.
● Audio Driver: Commonly Used drivers based on ALSA (Advanced Linux Sound Architecture, Advanced Linux Sound system)
● WiFi Driver: A Driver Based on the IEEE 802.11 standard
● KeyBoard Driver)
● Bluetooth Driver)
● Binder ipc driver: A special driver for Andoid. It has a separate device node and provides inter-process communication functions.
● Power Management (Energy Management)
(2) various Libraries and Android RunTime Environments)
This level corresponds to a General Embedded System, which is equivalent to a middleware level. Android has two levels: one is a variety of libraries and the other is the Android runtime environment. Most of the content at this layer is implemented using C ++. Among them, various libraries include:
● C Library: The standard library of C language, which is also the most underlying library in the system. C library is implemented through Linux system calls.
● Multimedia Framework (MediaFrameword): This part is the core of Android multimedia. Based on OpenCORE of PacketVideo (PV), this library is divided into two parts by function, one part is the PlayBack of audio and video (PlayBack), and the other part is the Recorder of audio and video ).
● SGL: 2D image engine.
● SSL: the Secure Socket Layer is located between the TCP/IP protocol and various application Layer protocols, providing security support for data communication.
● OpenGL ES 1.0: This section provides 3D support.
● Surface Management: This section provides functions for the Management and display subsystem.
● SQLite: A General Embedded Database
● WebKit: core of Web browsers
● FreeType: bitmap and vector font functions.
Android libraries are generally provided in the form of system middleware. A notable feature of these libraries is that they are closely related to the applications of mobile device platforms. The Android runtime environment mainly refers to the virtual machine technology Dalvik. The Dalvik virtual machine is different from the general JAVA Virtual Machine (Java VM). It does not execute the JAVA standard bytecode but the execution file in the Dalvik executable format (. dex. During execution, each application is a Process (a Process in Linux ). The biggest difference between the two is that Java VMS are Stack-based virtual machines, while Dalvik is Register-based ). Obviously, the biggest advantage of the latter is that it can achieve greater Optimization Based on hardware, which is more suitable for the characteristics of mobile devices.
(3) Application Framework)
The Android Application Framework provides APIs for developers at the application layer. It is actually an application framework. Because the upper-layer applications are built in JAVA, this layer first contains various controls required in the UI program: for example, Views (view components) include lists (list ), grids, text boxes, buttons, and even an embedded Web browser. An Android application can use the following components in the application framework: Activity, Broadcast Intent Receiver, and Service) and Content Provider ).
(4) Application)
Android applications are mainly User interfaces, which are usually written in JAVA and can contain various resource files (stored in the res directory ). After the JAVA program and related resources are compiled, an APK package is generated. Android provides many core applications such as Home, Contact, Phone, and browser. At the same time, application developers can use APIs at the application framework layer to implement their own applications.
Figure 1. hierarchical security architecture of Android

Component Model of Android)
The Android system includes four components:
(1) Activity
Activity is an interface where various controls can be placed. For example, the Task Manager interface and the Root Explorer interface. Activity is a visual user interface displayed for user operations. For example, an activity can display a menu item list for users to choose from, or display pictures containing instructions. A Short Message application can include an activity used to display the list of contacts who are sending objects, an activity that writes text messages to selected contacts, and a previous activity that reads text messages and changes settings. Although
They constitute a cohesive user interface, but each activity is independent of others. Each sub-class is implemented based on the Activity class.
An application can have only one activity, or, as mentioned in the text message application, it contains many. The role and number of each activity naturally depend on the application and its design. Generally, an application is marked as the first one you see when the application starts. The method for switching from one activity to another is to start the next activity based on the current activity.
Each activity is drawn by a default window. Generally, this window is full, but it can also be a small floating window located above other windows. An activity can also use more than one window. For example, a small dialog box pops up during the activity operation, or the necessary information displayed after the user selects a specific project on the screen.
The visible content displayed in a window is composed of a series of views that inherit from the View base class. Each View Controls a specific rectangular space in the window. The parent view contains and organizes the layout of its child view. The leaf node view (at the bottom of the view hierarchy) is drawn in the rectangle under their control and responds to users' direct operations. Therefore, a view is the interface on which the activity interacts with the user. For example, a view can display a small image and generate an action when the user instructs it. Android has many established views for users to use directly, including buttons, text fields, scrolls, menu items, check boxes, and so on.
(2) Service
A service is a function module running in the background. Such as file downloads and music playing programs. The Service does not have a visual user interface, but runs in the background within a period of time. For example, a service can play background music, obtain some data from the network, or compute some things in the background when the user is doing other things, and provide it to the activity that needs this calculation result. Each Service is inherited from the Service base class.
A media player plays a playlist in a sound example. The player application may have one or more activity to select a song and play it. However, the task of playing music itself should not be processed by any activity, because the user expects the music to continue playing when they leave the player application and start to do other things. For this purpose, the Media Player activity should enable a service running on the background. The system will continue to run the music play service after the activity is no longer displayed on the screen.
You can connect to (BIND) A Running Service (if the service is not running, start it ). After the connection, you can communicate with the service through the interface exposed by the Service. For music services, this interface allows users to pause, roll back, stop, and start playing again.
(3) Content Provider
It is a standard interface for data sharing between applications on the Android platform. It represents data in a way similar to URI (Universal Resources Identification), such as: content: // contacts/people/1101; the content provider provides specific application data to other applications. Data can be stored in a file system, SQLite database, or other methods. The content provider inherits from the ContentProvider base class and implements a set of standard methods for other applications to access and store the data it manages. However, the application does not directly call these methods, but uses a ContentResolver object to call its method as an alternative. ContentResolver can communicate with any content provider to manage all related interactive communication.
(4) Broadcast Receiver
Broadcast Receiver is a component that focuses on receiving and processing Broadcast notifications. Many broadcasts are derived from system code. For example, you are notified of time zone changes, low battery usage, taking a picture, or changing the language options. Applications can also be broadcast, such as notifying other applications that some data has been downloaded and is available.
Applications can have any number of Broadcast receivers to respond to all notifications that interest them. All receivers inherit from the BroadcastReceiver base class.
Broadcast Receiver has no user interface. However, they can start an activity to respond to the information they receive, or use icationicationmanager to notify users. Notifications can be used in many ways to attract users' attention-flashing back lights, vibrations, and playing sounds. In general, a persistent icon is placed on the status bar. You can open it and get the message.
The concept associated with this component is Intent, which is an abstract description of actions and actions, responsible for message transmission between programs between components. The Broadcast Receiver component provides a mechanism to Broadcast Intent as a message and respond to it by all programs interested in it. For example, to enable the function of playing music after a system is started, you can define Intent as android. intent. action. BOOT_COMPLETED, which is Broadcast by the Broadcast explorer component. Media Player in the system receives this information and then plays the video.
As mentioned above, the relationships between the four components are as follows:
Figure 2. Relationship between Android Components

Permission classification for Android
Based on the user experience, the permissions of Android can be roughly divided into the following three categories:
(1) permission of the Android mobile phone owner: After a user purchases an Android mobile phone, the user has the permission to install and use general applications without entering any password;
(2) Android root permission: this permission is the highest permission for the Android system and can be used to perform any operations on files and data in all systems. You do not have this permission by default when you leave the factory. You need to use z4Root and other software to obtain the permission. However, you are not encouraged to perform this operation because you may lose the original warranty of your mobile phone. Similarly, if you upgrade the root permission of your Android phone, you will be able to use the mobile phone with the Android root permission without entering any password.
(3) permission for Android applications: Android provides a wide range of sdks (Software development kit) that allow developers to develop Android applications. The application needs to have the corresponding access permission to the Android system resources. This permission is called the Android Application permission, which is set during application design, it takes effect upon initial installation of the Android system. It is worth noting that if the application is designed with a higher permission than the Android mobile phone owner, the application cannot run. For example, if the mobile phone does not obtain the Android root permission, the Root Explorer cannot be run because the Android root permission is required to run the application.
Android permission Definition
The Android system defines the Android user/user group in the/system/core/private/android_filesystem_config.h header file and sets permissions based on the user/user group.
 
# Define AID_ROOT 0/* traditional unix root user */
# Define AID_SYSTEM 1000/* system server */
# Define AID_RADIO 1001/* telephony subsystem, RIL */
# Define AID_BLUETOOTH 1002/* bluetooth subsystem */
# Define AID_GRAPHICS 1003/* graphics devices */
# Define AID_INPUT 1004/* input devices */
# Define AID_AUDIO 1005/* audio devices */
# Define AID_CAMERA 1006/* camera devices */
# Define AID_LOG 1007/* log devices */
# Define AID_COMPASS 1008/* compass device */
# Define AID_MOUNT 1009/* mountd socket */
# Define AID_WIFI 1010/* wifi subsystem */
# Define AID_ADB 1011/* android debug bridge (adbd )*/
# Define AID_INSTALL 1012/* group for installing packages */
# Define AID_MEDIA 1013/* mediaserver process */
# Define AID_DHCP 1014/* dhcp client */
# Define AID_SDCARD_RW 1015/* external storage write access */
# Define AID_VPN 1016/* vpn system */
# Define AID_KEYSTORE 1017/* keystore subsystem */
# Define AID_USB 1018/* USB devices */
# Define AID_DRM 1019/* DRM server */
# Define AID_DRMIO 1020/* drm io server */
# Define AID_GPS 1021/* GPS daemon */
# Define AID_NFC 1022/* nfc subsystem */
# Define AID_SHELL 2000/* adb and debug shell user */
# Define AID_CACHE 2001/* cache access */
# Define AID_DIAG 2002/* access to diagnostic resources */
/* The 3000 series are intended for use as supplemental group id's only.
* They indicate special Android capabilities that the kernel is aware .*/
# Define AID_NET_BT_ADMIN 3001/* bluetooth: create any socket */
# Define AID_NET_BT 3002/* bluetooth: create sco, rfcomm or l2cap sockets */
# Define AID_INET 3003/* can create AF_INET and AF_INET6 sockets */
# Define AID_NET_RAW 3004/* can create raw INET sockets */
# Define AID_NET_ADMIN 3005/* can configure interfaces and routing tables .*/
# Define AID_MISC 9998/* access to misc storage */
# Define AID_NOBODY 9999
# Define AID_APP 10000/* first app user */
 
It is worth noting that after each application is installed on the Android system, the system will assign a user ID for it, such as app_4 and app_11. The following are the browsing results of the Calendar and Terminal software processes in the Android system (in which the user ID assigned to the application is indicated by the black font ):
 
USER PID PPID VSIZE RSS WCHAN PC NAME
App_16 2855 2363 216196 20960 ffffffff afd0ee48 S com. android. providers. calendar
App_91 4178 2363 218872 25076 ffffffff afd0ee48 S jackpal. androidterm
In the Android system, the above user/user group's access to files follows the access control principle of the Linux system, that is, the user/user group's access to the file is determined based on a 10-character permission control. The rule is as follows:
● 1st characters: indicates a special file type. The characters can be d (indicating that the file is a directory) and B (indicating that the file is a system device, and the block input/output is used to interact with the outside world, usually a disk), c (indicates that the file is a system device that uses continuous character input/output to interact with the outside world, such as the serial port and sound device), ". this file is a common file with no special attributes.
● 2 ~ 4 characters: used to determine the user permissions of the file;
● 5 ~ 7 characters: used to determine the object group permissions;
● 8 ~ 10 characters: used to determine the permissions of other users (other user, neither the file owner nor members of the group) of the file.
● The characters 2nd, 5, and 8 are used to control the read permission of a file. The character r indicates that users, group members, or others can read data from the file. "-" Indicates that the member is not allowed to read data.
● Write permission for a 3rd, 6, or 9-bit character control file. If the bit is w, the write permission is allowed. If the bit is "-", the write permission is not allowed.
● 4th, 7, and 10 characters are used to control the file manufacturing permission. If this digit is x, execution is allowed. If it is "-", execution is not allowed.
For example, "drwxrwxr-2 root 4096 February 11 10:36 lu" indicates the access control permission (marked in black): Because lu's 1st characters are d, therefore, lu is a directory. Rwx indicates that the user root has the permission list to display all files in lu, create new files, delete existing files in lu, or use lu as the current working directory. The permissions from 5th to 7 locations are rwx, indicating that the root group members have the same permissions as root members. The 8th-10-bit permission is only r-, indicating that a user who is not the root user and a member who is not in the root group only has permissions on the lu directory list. These users cannot create or delete files in lu, execute executable files in junk, or use junk as their current working directory.
Android Application permission Application
Each application's APK package contains an AndroidMainifest. xml file. In addition to listing the library used for running the application program and running dependencies, the file also lists the system access required by the application in detail. When developing application software, the programmer needs to explicitly apply for access permissions to the Android system by setting the uses-permission field of the file.
AndroidMainifest. xml file usage
AndroidManifest. xml mainly includes the following functions:
1. indicates the java data packet of the application. The data packet name is the unique identifier of the application;
2. Describe application component;
3. Describe the process in which the component of the application runs;
4. Declare the permissions required by the application to access protected APIs and interact with other applications;
5. Declare other necessary permissions of the application for component interaction;
6. List the environment configuration information required for application running. The declaration information only exists during program development and testing and will be deleted before release;
7. Declare the minimum Android API versions required by the application, such as 1.0, 1.1, and 1.5;
8. List the databases required by the application;
 
AndroidManifest. xml file structure and elements
The structure, elements, and attributes of the AndroidManifest. xml file can be viewed in the Android SDK documentation. Before looking at these elements and their attributes, you must first understand the naming and structure rules of these elements:
1. element: only the sum of all elements is required and can only appear once. If an element contains other child elements, its value must be set through the attributes of the child element. Elements at the same level have no order.
2. attributes: according to common sense, all attributes are optional, but some attributes must be set. The optional attributes have default value descriptions even if they do not exist. Except for the root element attributes, the names of all other element attributes are prefixed with android;
3. Define a class name: All element names correspond to their class names in the SDK. If you define a class name, it must contain the class data packet name, if the class is in the same data packet as the application, you can simply abbreviated it as ". ";
4. Multiple value items: if an element has more than one value, the element must be repeated to indicate that an attribute has multiple value items, multiple numeric values cannot be described in one attribute at a time;
5. Resource Description: When a resource needs to be referenced, the format is as follows: @ [package:] type: name. For example
6. String Value: similar to other languages. If the character contains the character "\", the escape character "\" must be used.
The following describes the AndroidManifest. xml file in the cookie instance. The original XML file is as follows:
 
<? Xml version = "1.0" encoding = "UTF-8"?>
<Manifest xmlns: android = "http://schemas.android.com/apk/res/android"
Package = "moandroid. cookie"
Android: versionCode = "1 ″
Android: versionName = "1.0">
<Application android: icon = "@ drawable/icon" android: label = "@ string/app_name">
<Activity android: name = ". cookie" android: label = "@ string/app_name">
<Intent-filter>
<Action android: name = "android. intent. action. MAIN"/>
<Category android: name = "android. intent. category. LAUNCHER"/>
</Intent-filter>
</Activity>
</Application>
<Uses-sdk android: minSdkVersion = "3"/>
</Manifest>
In addition to the XML Information in the header, the first is the manifest item (that is, the root node). Its attributes include: schemas URL address, package name (moandroid. cookie), and the version of the program. The second is the manifest subnode application. Its attributes include: program icon and program name. A resource is referenced by @. For example, @ drawable/icon indicates that the icon in the drawable resource is referenced, which can be found in res/drawable of its source project. Then, the application's subnode activity has the following attributes: activity name and activity tag name. Its subnode intent-filter describes the activity.
In intent-filter, action android: name = "android. intent. action. MAIN "and category android: name =" android. intent. category. LAUNCHER is used to indicate the entry activity at the startup of the program. If the two property values contain MAIN and LAUNCHER respectively, it indicates that it is the entry activity when the program is started. Uses-sdk android: minSdkVersion = "3" indicates the minimum version of the Android SDK used by the program. 1 indicates Android 1.0, 2 indicates Android 1.1, and 3 indicates Android 1.5.
How to Apply for application Permissions
As shown in the following figure, the parts marked in the text are the application permission application content:
 
<? Xml version = "1.0" encoding = "UTF-8"?>
<Manifest xmlns: android = "http://schemas.android.com/apk/res/android"
Package = "cn.com. fetion. android"
Android: versionCode = "1"
Android: versionName = "1.0.0">
<Application android: icon = "@ drawable/icon" android: label = "@ string/app_name">
<Activity android: name = ". welcomActivity"
Android: label = "@ string/app_name">
<Intent-filter>
<Action android: name = "android. intent. action. MAIN"/>
<Category android: name = "android. intent. category. LAUNCHER"/>
</Intent-filter>
</Activity>
</Application>
<Uses-permission android: name = "android. permission. SEND_SMS"> </uses-permission>
</Manifest>
For example, the Italic section in the description of the preceding file, which indicates that the software needs to send text messages.
Android defines more than permission types for developers. For details, see http://developers.androidcn.com/reference/android/manifest.permission.html.
In the file, you can also customize permissions. Permission is a declaration of custom permissions. It can be used to restrict access to special components in an app, including features within the app or between other apps. I wrote an example to reference custom permissions. When installing the app, the following message is displayed:
The permission is defined as follows:
 
<Permission android: label = "" Custom permission ""
 
Android: description = "@ string/test"
 
Android: name = "com. example. project. TEST"
 
Android: protectionLevel = "normal"
 
Android: icon = "@ drawable/ic_launcher">
The meaning of the statement is as follows;
Android: label: Permission name, which is displayed to the user. The value is a string, for example, "Custom permission ".
Android: description: a longer permission description than label. The value is obtained through the resource file and cannot be written directly to the string value. For example, "@ string/test" here ".
Android: name: Permission name. This parameter is required if other apps reference this permission.
Android: protectionLevel: Permission level, which can be divided into four levels:
○ Normal: low-risk permission. During installation, the system automatically grants the permission to the application.
○ Dangerous: high-risk permissions. The system does not automatically grant permissions to the app. When used, users are prompted.
○ Signature: signature permission. When other apps reference declared permissions, ensure that the signatures of the two apps are consistent. In this way, the system automatically grants permissions to third-party apps without prompting users.
○ SignatureOrSystem: this permission is the permission that the app that references this permission must have the same signature as the system to grant. It is generally not recommended.
It is worth noting that the test shows that an application can apply for root permissions when running the program. For example, when using Android Terminal Emulator, try to use the su command to switch to the root user. If the Android system has obtained the root permission through hacking, the program can be executed with the root user permission. Otherwise, the user selects "allow ", the program cannot be executed as the root user.
Figure 3. grant permissions to Android users

Analysis on how the Android system processes application permission applications
Analyze the following files in the Android source code:
● InstallAppProgress. java: the path is \ packages \ apps \ PackageInstaller \ src \ com \ android \ packageinstaller \ InstallAppProgress. java;
● PackageInstallerActivity. java: the path is \ packages \ apps \ PackageInstaller \ src \ com \ android \ packageinstaller \ PackageInstallerActivity. java;
● AppSecurityPermissions. java: the path is \ frameworks \ base \ core \ java \ android \ widget \ AppSecurityPermissions. java.
The following figure shows how the Android system processes the application Authorization application:
● Enter the entry function for processing the application Authorization application;
● The system obtains the permission list required for normal operation of the application from the AndroidManifest. xml file of the installed application;
● A dialog box is displayed, requesting the user to confirm whether these permissions are met;
● If you agree, the application will be installed normally and the corresponding permissions will be granted; otherwise, the application will not be installed. The system only provides the right to select "yes" or "no" for users, but does not have the right to select some of the permissions for authorization.
Figure 4. grant permissions to Android users