Android security mechanism Introduction, android Mechanism

Android security mechanism Introduction, android Mechanism

Android security mechanisms include the following:

• Process sandbox isolation mechanism. • Application signature mechanism. • Permission declaration mechanism. • Access control mechanism. • Process communication mechanism. • Memory management mechanism. • SELinux

I. Process sandbox isolation mechanism

The Android Application is assigned a unique user ID (UID) during installation and is permanently maintained. The application and its running Dalvik virtual machine run in an independent Linux Process space, applications with different UIDs are completely isolated.

II. Application signature mechanism

The application package (.apk file) must be digitally signed by the developer. The same developer can specify different applications to share the UID, and then run in the same process space to share resources.

Signature process:

• Generate private, public key, and Public Key Certificates • sign applications • optimize applications

Signature function:

• Identify the author of the Code. • Check whether the application has changed. • Build trust between applications so that applications can securely share code and data.

Iii. Permission declaration mechanism

The application must explicitly declare the permission, name, permission group, and protection level. Different levels require different authentication methods for applications to exercise this permission: Normal Application can be used; Dangerous level must be confirmed by the user during installation; signature and Signatureorsystem must be system users. • Declare the following attributes in the manifest File

<Uses-permissionandroid: name = "string"/>

Request permissions for android: name.

• Add custom permissions using the following attributes

<Permission

Xmlns: android = "http://schemas.android.com/apk/res/android"

Android: name = "com. test. android. ACCESS_FRIENDS_LIST"

Android: description = "@ string/permission_description"

Android: label = "@ string/permission_label"

Android: protectionLevel = "normal"/>

• System component permissions, such as activity components

<Activity

Android: permission = "com. test. android. ACCESS_FRIENDS_LIST"

Iv. Access Control Mechanism

The traditional Linux access control mechanism ensures that the system files and user data are not illegally accessed. Linux users and permissions • Super Users (root), with the highest system permission, UID is 0. • Pseudo-users in the system. The Linux operating system is unwilling to grant super-user permissions due to system management needs. It is necessary to grant ownership of some key system application files to some pseudo-users in the system, the UID range is 1 ~ 499. pseudo users of the system cannot log on to the system.

• Common users only have limited access permissions. The UID is 500 ~ 6000. you can log on to the system to obtain the shell

In the Linux permission model, each file belongs to one user and one group, and the ownership is identified by UID and GID. Specific File Access Permissions

It is defined as readable (r), writable (w), and executable (x), and describes related permissions by a set of three permissions: read, write, and execute.

The first group defines the permissions of the file owner (user), the second group defines the permissions of the same group of users (users with the same GID but different UID), and the third group defines

Permissions of other users (users with different GID and UID ).

5. Process Communication Mechanism

The Binder Process Communication Mechanism provides efficient process communication based on the shared memory; the Binder Provides Lightweight Remote Process calling (RPC) similar to COM and CORBA Based on the Client-Server mode ); the Interface Description Language (AIDL) is used to define the interface and the data exchange type, so as to ensure that the data for inter-process communication does not overflow across borders and pollute the process space.

Vi. Memory Management Mechanism

Based on the standard Linux Low Memory Management Mechanism (OOM), the design implements a unique low memory cleaning (LMK) mechanism to classify and group processes by importance. When the memory is insufficient, it automatically clears the memory space occupied by the lowest-level process. At the same time, it introduces the Android shared memory mechanism Ashmem, which is different from the traditional Linux shared memory mechanism, and is capable of clearing the shared memory areas that are no longer used.
VII. SELinux

SELinux has three basic operation modes

• Disabled: Disable SELinux policy • Permissive: in Permissive mode, SELinux is enabled, but security policies are not implemented. Instead, SELinux only sends warnings and records row actions. Permissive mode is useful when SELinux is excluded • Enforcing: This default mode enables and implements SELinux security policies on the system, and denies access and records actions.

SELinux has three access control methods:

• Force type (TE): TE is the main access control mechanism adopted by type policies. • Role-Based Access Control (RBAC): it uses SELinux users (not necessarily equivalent to Linux Users) but the default targeting policy does not use it • Multi-Layer Protection (MLS): not used, and often hidden in the default targeting policy.
SELinux policy file:

• In the android/external/sepolicy directory

• Wing-common/sepolicy custom policy

SELinux default macro:

• Global_macros • mls_macros • te_macros
Common SELinux concepts
• Subject: In SELinux, a subject usually refers to a process. • Object: objects are usually system resources (such as files, directories, sockets, and shared memory ). • Object Type: an object type represents all resources of a certain type (such as a file or socket. • DAC: access control based on user identification in Linux. • MAC: the access type used by the subject to the object, that is, force access control (TE ). • Type-forced security context: an access attribute is called a security context. A security context includes the user, role, and type identifier.
• Domain: for historical reasons, a process type is usually called a domain or domain type. We believe that the domain, domain type, subject type, and process type all share the same meaning. • Policy: Because SELinux does not allow any access by default, in SELinux, the subject is authorized to access the object through the allow statement. • Domain Conversion
SELinux policy

Selinux policy language currently supports four types of AV rules:

The allow, dontaudit, auditallow, and neverallow rules are composed of four parts.

• The Source Type (SourceType) is usually the type of the domain that attempts to access the process. • TargetType: the type of the object accessed by the process. • ObjectClass: the types of objects that can be accessed (such as file, dir, and socket ). • Permission indicates the type of access that the target allows to access the object type from the source type. • For example, allowdev_type tmpfs: filesystem associate;
SELinux domain Conversion
• Condition for domain conversion • the new domain type of the process has the entrypoint access permission on the executable file type • The domain type of the process has the execute access permission on the entry file type • the current domain type of the process the domain type of has the transition access permission.
SELinux attributes

Attribute can be understood as "type set with a set of commonalities" or "commonalities of this set of types ". Syntax:

Attribute attribute_name;

For example, define an attribute named "file_type:

Attribute file_type;

When defining a type, establish its association with an attribute, for example:

Type shadow_t, file_type;

Attribute can effectively reduce the number of similar rules. For example, to enable domain = backup_t to read all files in the file system

In theory, the corresponding allow rules must be defined for all possible file types:

Type backup_t;

Allow backup_t shadow_t: file read;

Allow backup_t var_t: file read;

Attribute can be used to effectively solve this problem,

Allow backup_t file_type: file read;

SELinux role
SELinux implements role-Based Access Control through Role in SC ). In SELinux, roles are used as a bridge instead of directly establishing the relationship between users and types.

User u roles {r}

Role r types domain;

SELinux Access Control
• Ls-Z displays the security context of the file system object • Ps-Z displays the security context of the Process • displays "User: Role: Type: security level 」
SELinux Problem Analysis

When SELinux is in the enforcing mode, the execution of some programs will fail. Here we will summarize the overall analysis method for such problems.

• First, remove the DAC permission and use "ls-l" to check the owner and permissions of the relevant files. If the DAC permission permits, The SELinux policy explicitly rejects the execution of the current operation. • Check the role currently played by the user. Some operations can be performed only by a specific role. • Enter the permissive mode, and identify the root cause of the problem from the AVC Denied Msg corresponding to the analysis failure operation.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.