Android 8.1 security mechanism — seoandroid & SELinux

Time:2021-4-11

1. SELinux background knowledge

1.1 DAC and MAC

Before SELinux appeared, the security model on Linux was called DAC, whose full name was discrete access control, translated as autonomous access control.

The core idea of DAC is very simple, that is: the process theoretically has the same permissions as the user who executes it. For example, if you start browser as root user, browser has the authority of root user and can do anything on Linux system.

Obviously, Dad management is too loose, as long as you find a way to get root permission on Android system. So how does SELinux solve this problem? Besides DAC, it designs a new security model called MAC (mandatory access control), which translates into mandatory access control.

The theory of MAC is also very simple. Any process that wants to do anything on SELinux system must be given permission in the security policy file. If the permission does not appear in the security policy file, it will not work.

There are several knowledge points about DAC and MAC

  1. Do DAC check for Linux system first. If the DAC permission check is not passed, the operation fails directly. After passing the DAC check, check the MAC authority
  2. SELinux has its own set of rules for writing security policy files, which is called SELinux policy language.

1.2 sepolicy language

There are two things in Linux, one is inactive, the other is active. The dead thing is a file (Linux philosophy, everything is a file). Note that it can not be narrowly interpreted as “file”, and the living thing is the process. Dead and alive here is a metaphor, mapped to the software level, which means that a process can initiate an action, for example, it can open a file and operate it. Files can only be operated by processes.

According to SELinux specification, the complete secure context string is as follows: user:role :type[:range]

1.2.1 secure context of process

In SELinux, everything is given a security attribute, which is officially called security context. Security context is a string, which is mainly composed of three parts. For example, in seoandroid, the security context of a process can be viewed through PS – Z command

rk3288:/ $ ps -AZ
u:r:hal_wifi_supplicant_default:s0 wifi      1816     1   11388   6972 0                   0 S wpa_supplicant
u:r:platform_app:s0:c512,c768  u0_a14        1388   228 1612844  57396 0                   0 S android.ext.services
u:r:system_app:s0              system        1531   228 1669680 119364 0                   0 S com.android.gallery3d
u:r:kernel:s0                  root           582     2       0      0 0                   0 S [kworker/1:2]
u:r:radio:s0                   radio          594   228 1634876  89296 0                   0 S com.android.phone
u:r:system_app:s0              system         672   228 1686204 141716 0                   0 S com.android.settings
u:r:platform_app:s0:c512,c768  u0_a18         522   223 1721656 152116 0                   0 S com.android.systemui

The leftmost column above is the security context of the process, with the first process WPA_ Supplicant as an example

u:r:hal_wifi_supplicant_default:s0

Among them:

  • U means user. A SELinux user is defined in seoandroid with the value of U
  • R is the meaning of role, and role is the meaning of role. It is a higher level and more convenient permission management idea in SELinux. In short, a u can belong to multiple roles, and different roles have different permissions.
  • hal_ wifi_ supplicant_ Default means that the domain to which the process belongs is Hal_ wifi_ supplicant_ default。 The basic management idea of MAC (mandatory access control) mandatory access control is actually type enforcement access control (teac for short, generally expressed by TE). For processes, type is domain, such as Hal_ wifi_ supplicant_ All permissions required by default need to be explained in the te file through the allow statement.
  • S0 is a multi level security (MLS) mechanism designed by SELinux to meet the needs of military and education industries. To put it simply, MLS classifies the processes and files of the system, and different levels of resources need corresponding levels of processes to access

1.2.2 secure context of file

The secure context of the file can be viewed through LS – Z, as follows

rk3288:/vendor/lib $ ls libOMX_Core.so -Z
u:object_r:vendor_file:s0 libOMX_Core.so
  • u: It also means user. It represents the SELinux user who created this file
  • object_ r: Files are dead things. They can’t play a role, so in SELinux, objects are used for dead things_ R for its role
  • vendor_ File: type, which means the same as the domain of the process, represents libomx_ Core.so The type of the file is vendor_ file
  • S0: the level of MLS

1.3 te introduction

The basic management unit of MAC is teac (type enforcement access control), followed by the higher level role based access control. RBAC is based on te, and Te is the most important part of SELinux. The allow statement mentioned above is the category of te.

According to SELinux specification, the complete SELinux policy rule statement format is as follows:

allow domains types:classes permissions;

-Domain - the label of a process or group of processes. Also known as a domain type, because it refers only to the type of process.
-Type - the label of an object (for example, file, socket) or a group of objects.
-Class - the type of object (for example, file, socket) to access.
-Permission - the operation to be performed (for example, read, write).

=Allow: allows the subject to operate on the object
=Never allow: refuse the subject to operate on the object
=Dontaudit: indicates that the decision information of a rule violation is not recorded
=Auditallow: records the information of a decision. Usually, SELinux only records the information of failure. After applying this rule, it will record the information of successful decision.

Examples of structures to follow when using policy rules:

sentence:
allow appdomain app_data_file:file rw_file_perms;

This means that all application domains can read and write with app_ data_ File label file

– > related examples

1. Security policy file in seondod policy.conf
#Allow processes in the zygote domain to send sigchld signals to processes in the init domain (object class is process)
allow zygote init:process sigchld;
2. Allow the process in the zygote domain to search or getattr the directory of type AppDomain.
#Note that multiple perms_ Set can be enclosed by {}
allow zygote appdomain:dir { getattr search };

3. # perm_ The syntax of set is strange, with a ~ sign in front.
   #It means {Chr} except {entrypoint relabelto}_ File # file}_ Other operations owned by class 
  allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file }   \
  ~{entrypoint relabelto};

Recommended Today

Analysis of super comprehensive MySQL statement locking (Part 1)

A series of articles: Analysis of super comprehensive MySQL statement locking (Part 1) Analysis of super comprehensive MySQL statement locking (Part 2) Analysis of super comprehensive MySQL statement locking (Part 2) Preparation in advance Build a system to store heroes of the Three KingdomsheroTable: CREATE TABLE hero ( number INT, name VARCHAR(100), country varchar(100), PRIMARY […]