Briefly describe the te of SELinux in Android

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

The kernel exposes the resource permissions allowed to be accessed to the outside, and te describes what access rights the subject has. SELinux defines 30 different object categories:

Each object category defines an operation license. For example, there are 19 operation licenses for file:

These two contents will be covered later when introducing common grammar. Therefore, for the operation permission of file, we can see that it is basically the operation method of file, so when the program calls these functions, the system will check whether there is a te rule that grants the program permission to use this function.

2.1 enable SELinux

First, you must turn on the SELinux function. Google provides a switch to turn on this option. The following variables are defined in boardconfig.mk:

There will be many te files under the corresponding path to describe the process's access permission to resources.

2.2 declaration type

2.3 association types and attributes

There are two ways to associate a type with a property.

1、 When a type is declared, the defined attributes are associated.

This is defining the system_ When you create an app, you associate it with the defined domain attribute.

If the type platform has been defined_ App, which can be associated with the defined mistrusted subject with a typeattribute.

Note: all attributes and types share the same namespace, so don't appear attributes and types with the same name when naming.

AV is used to describe the access permission of the subject 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.

Never allow: indicates that the subject is not allowed to perform the specified operation on the object.

Auditallow: indicates that operations are allowed and access decision information is recorded.

Don't audit: it means that the decision information violating the rules will not be recorded. If the rules are violated, the operation will not be affected

Common type rule syntax bits:

Indicates that the category is platform_ The app program process performs read and IOCTL operations on debugfs type files.

"Permitted": all operations are allowed (i.e. there is no MAC), but if there is a violation of permissions, the log "enforcing" will be recorded: all operations will be checked for permissions

The following functions often appear in te files:

This is actually a macro. It is defined in the file name te_ In the macros file, after searching the macro globally, the following definitions are found:

In fact, it is also an allow access vector.

7、 Summary

Keep in mind that te rules describe the permission of the subject to access the object. The smallest unit of te is type, which abstracts subject and object. Each subject needs to have a corresponding AV rule description to execute a certain permission to the object, otherwise it will fail. If you encounter relevant problems in the actual project process, you may need to modify te files and edit relevant operation licenses.

summary

The above is the te of SELinux in Android introduced by Xiaobian. I hope it will help you. If you have any questions, please leave me a message, and Xiaobian will reply to you in time. Thank you very much for your support for the programming tips website!