Brief introduction of TE of SELinux in Android

1. Basic concepts of SELinux resource access

SELinux uses type coercion to improve mandatory access control. All subjects (program processes) access to objects (files/socket and other resources) is permitted by an TE rule. When the program accesses a resource, the system will search all TE rule sets and process according to the results. This rule set is described by access vector rules (AV, Access Vector).

The kernel exposes the resource permissions allowed to access to the outside, and TE describes what kind of access the principal has. SELinux defines 30 different object categories:

security process system capability filesystem file dir fd lnk_file chr_file blk_file socket_file ...

Each object category defines operational permissions, such as 19 operational permissions for file:

ioctl read write create getattr setattr lock relablefrom relableto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint

These two contents will be involved in the introduction of common grammar later. Therefore, for the operation license of file, we can see that it is basically the operation method of files, so when the program calls these functions, the system will check whether there is an TE rule that grants the program permission to use this function.

2. SELinux in Android

2.1 Turn on SELinux

The SELinux function must be turned on first, and google provides a switch to turn this option on. The following variables are defined in BoardConfig. mk:

BOARD_SEPOLICY_DIRS += build/target/board/generic/sepolicy

There are many TE files below the corresponding path to describe the access permission of the process to the resource.

2.2 Declaration Type

type  Type name  
type system_app;

2.3 Association Types and Attributes

There are two ways to associate a type with an attribute.

1. Associate the defined attributes when declaring the type.

type system_app, domain;

This associates system_app with the domain attribute already defined when defining it.

typeattribute platform_app mlstrustedsubject;

If you have defined the type platform_app, you can associate it with the mIstrustedsubject you have defined with typeattribute.

Note: All attributes and types share 1 namespace, so do not have the same name when naming attributes and types oh.

3. Access Vector (AV) Rule

AV is used to describe the subject's access permission to the object. There are usually four types of AV rules:

allow: Indicates that the subject is allowed to perform permitted operations on the object.

neverallow: Indicates that the subject is not allowed to perform the specified operation on the object.

auditallow: Indicates that the operation is allowed and that access decision information is recorded.

dontaudit: It means that the decision information of violating the rule is not recorded, and the violation of the rule will not affect the operation

Generic type rule syntax bits:

allow platform_app debugfs:file { read ioctl };

Represents a program process of class platform_app that performs read and ioctl operations on files of type debugfs.

4. 1 Some special configuration files:

external/sepolicy/attributes ->  All defined attributes It's all in this file  
external/sepolicy/access_vectors ->  Corresponds to every 1 A class Commands that can be allowed to be executed  
external/sepolicy/roles -> Android Only defined in the 1 A role The name is r , will r And attribute domain Connect  
external/sepolicy/users ->  In fact, it will user And roles Has been associated and set up user The security level of, s0 The lowest level is the default level, mls_systemHigh Is the highest level  
external/sepolicy/security_classes ->  Refers to the above order class Personally, I think this class The content of refers to the content in android Module of operations that may be used by a program or system during operation  
external/sepolicy/te_macros ->  System-defined macros are all in te_macros Documents  
external/sepolicy/*.te -> 1 Some configuration files, including various running rules 

5. selinux has two modes of operation

"permissive": All operations are allowed (i.e. no MAC), but if there is a permission violation, it is logged
"enforcing": All operations are checked for permissions

6. Others

The following functions often appear in te files:

unix_socket_connect(platform_app, agpsd, mtk_agpsd);

This is actually a macro. It is defined in a file named te_macros. After searching this macro globally, we find the following definition:

 unix_socket_connect($1, qmuxd, qmux)
 allow qmux $1_qmuxd_socket:sock_file { getattr unlink };
 ')

It is also an allow access vector.

7. Summary

Always keep in mind that TE rules describe the permission of subjects to access objects. The smallest unit of TE is type, a concept that abstracts subjects and objects. Each subject must have a corresponding av rule description if it executes some kind of permission to an object, otherwise it will fail. In the actual project process, if you encounter related problems, you may need to modify the te file and edit the relevant operation permission.

Summarize