Introduction to SELinux rule analysis and syntax in Android

#############################################

This article is extremely ice original, reprint please indicate source #############################################

1. SELinux can be understood as a security mechanism on Android, a security strengthening system designed for Linux by the NSA and some companies
We can customize some of the permissions of our phone by configuring the policy of SELinux, for example, we can completely let the root user have no permissions as user
2. In Android, there are two types, one is file, and the other is process.
For both types, we can start by looking at their differences.
On Android, after the ADB shell enters the phone, ps-z can view the SELinux permissions that the current process has.


Example:

LABEL USER PID PPID nameu:r:init:s0 root 1 0/initu:r:kern  EL:S0 Root 2 0 kthreadd...u:r:kernel:s0 root 258 2 Irq/322-hph_r     Ou:r:logd:s0 logd 259 1/system/bin/logdu:r:healthd:s0 Root 260 1    /SBIN/HEALTHDU:R:LMKD:S0 Root 261 1/system/bin/lmkdu:r:servicemanager:s0 system 262 1/system/bin/servicemanageru:r:vold:s0 Root 263 1/system/bin/voldu:r:surfacef LINGER:S0 system 1/system/bin/surfaceflingeru:r:tctd:s0 Root 265 1/s YSTEM/BIN/TCTDU:R:RFS_ACCESS:S0 System 268 1/system/bin/rfs_accessu:r:tee:s0 Sy                  Stem 271 1/system/bin/qseecomdu:r:kernel:s0 Root 280 2 Kworker/3:1hu:r:kernel:s0      Root290 2 Kauditdu:r:rmt_storage:s0 Nobody 291 1/system/bin/rmt_storageu:r:shell:s0 Shell 292 1/system/bin/shu:r:netd:s0 Root 295 1/system/bin/netdu:r:debuggerd : S0 Root 296 1/system/bin/debuggerdu:r:tee:s0 system 297 271/system/ Bin/qseecomd

In this case, we can do the analysis.
In Android, only one user is defined as U. In addition, if it is a process, it will be uniformly defined as r, and if it is a file, it will be defined as Object_r. The third is the process type, which defines more than 100 types in Andorid. As I understand it, this is the type of > that the process belongs to. The fourth one is S0, this is a safe grade. But for the time being, there is no place to configure this.


Also is the file, the file wants to see the related SELinux permission, need to execute ls-z

Drwxr-x--x root     sdcard_r          u:object_r:rootfs:s0 storagedrwx--x--x root     root              u:object_r:tmpfs:s0 Synthesisdr-xr-xr-x root     root              u:object_r:sysfs:s0 sysdrwxr-xr-x root     root              u:object_r:system_file: S0 systemdrwxrwxr-x system   tctpersist          u:object_r:tct_persist_file:s0 tctpersistlrwxrwxrwx root     root              U:object_r:rootfs:s0 Tombstones-/data/tombstones-rw-r--r--root     root              u:object_r:rootfs:s0 ueventd.qcom.rc-rw-r--r--root     root              u:object_r:rootfs:s0 ueventd.rc

In this example, combined with the above analysis, we know that Object_r is the representative of the file, U is the only user of Android, Rootfs is the corresponding type of this file, S0 is a security level limit.


3. How to configure SELinux


First, follow Google's official documentation:
Requires the Linux kernel to support SELinux first, and also requires the Android SELinux configuration file, which is the contents of Extern/sepolicy.
And then modify Boardconfig.mk.
Google's Nexus Sepolicy support is on the Device/lge/mako/sepolicy
First, the vendor-customized Sepolicy folder will be included: Board_sepolicy_dirs
The rules are then added to Sepolicy: board_sepolicy_dirs


In this case, the image we compiled is actually a function of SELinux.
In fact, if there is no vendor customization, it will be compiled to External/sepolicy, so that is the use of andriod all the default Sepolicy (It defines the domains and types for the AOSP Services and apps common to all devices. ）


Then after understanding this, we can see in fact a lot of manufacturers also have their own configuration rules under Device/***/***/sepolicy.

4. SELinux Configuration rules:
The first thing to understand is the structure of Sepolicy:
A. App process-Mac_permissions.xml
B. App data file-seapp_contexts
C. system file, file_contexts
D. System Properties-property_contexts


In the Te file, the syntax we typically encounter is this:
Rule_name Source_type Target_type:class Perm_set
READ: To set a rule_name rule for source_type, the rule is to perm_set the Target_type class.


Then there are some special configuration files:
A. All definitions of attributes in this file external/sepolicy/attributes
B. external/sepolicy/access_vectors, which corresponds to every command that a class can be allowed to execute
C. Only one role is defined in Android External/sepolicy/roles, and the name is R, associating R with attribute domain.
D. external/sepolicy/users is actually associating user with roles, setting the user's security level, S0 the lowest level is the default level, Mls_systemhigh is the highest level
E. External/sepolicy/security_classes refers to the class in the above command, which personally considers the content of this class to refer to the module of operations that may be used by the program or system during Android operation.
F. External/sepolicy/te_macros-system-defined macros are all in the Te_macros file
F. Some of the configured files, External/sepolicy/***.te, contain rules for various operations

In addition, SELinux has two modes of operation:
"Permissive": all operations are allowed (that is, no Mac), but logging is logged if there is a violation of permissions
"Enforcing": all operations will be checked for permissions

Finally, the type command is as follows:
Type type_id [alias alias_id,] [attribute_id] # Associates type_id (alias aliases) to attribute. In this case, it is convenient to use attribute to manage parts of different types that contain the same attributes.

The format of the Class command is:
Class Class_name [Inherits Common_name] {Permission_name ...}
Inherits means that the permissions defined by the common are inherited, and then the Permission_name permissions are implemented by themselves.


The four named rules that are common in te files:
Allow: Gives a permission.
The Allowaudit:audit meaning is to record an action. By default, SELinux records only those actions that failed the permission check. Allowaudit the successful operation of the permission check is also logged. Note that Allowaudit just allows logging, and it does not matter which permissions are granted. Permissions must be granted and only the
Use the Allow statement.
Dontaudit: Do not record those operations that have failed the permission check.
Neverallow: Previously mentioned, used to check if there are allow statements in the security policy file that violate this rule. As shown in Example 5:

Example:

Type init, domain;
Associating init to domain, setting domain as a property of the Init type

Allow Init Unlabeled:filesystem mount;
Allows the init type to mount the filesystem of the unlabeled type

Allow init Fotad:unix_stream_socket {bind create};
Allow init type to bind and create for Unix_stream_socket of type Fotad

Allow AppDomain Anr_data_file:dir search;
Allow AppDomain anr_data_file:file {open Append};
First the AppDomain is a macro defined in the Te_macros, and many app rules will add it using a command like App_domain (Shell).
The meaning of these two words is: 1. Allow apps to look for directories of type Anr_data_file
2. Allow the app to open and add to the Anr_data_file type of file is defined as the time when the ANR, the app to/data/anr/write permission restrictions

Neverallow {Appdomain-unconfineddomain} kmem_device:chr_file {Read Write};
Never allow apps (except apps with Unconfineddomain properties) to read and write to kmem_device types of character devices

Neverallow {Appdomain-unconfineddomain} Self:capability2 *;
Do not allow apps other than unconfineddomain to do anything to the self type of capability2

Type httpd_user_content_t, File_type, httpdcontent;
Declares a httpd_user_content_t type, with properties of File_type and Httpdcontent

Type httpd_user_content_t;
Typeattribute httpd_user_content_t File_type, httpdcontent;
Declaring a type of httpd_user_content_t
Defines httpd_user_content_t with File_type, httpdcontent properties

Allow AppDomain Self:rawip_socket create_socket_perms;
All the types that can be set can actually be set as properties.
For example, we allow all content with the app property to go to the rawip_socket of the Self property to create the operation

Allow {user_t domain} {bin_t File_type sbin_t}:file execute;
Allows classes of user_t and domain properties to perform operations on bin_t, File_type, and sbin_t file types

Allow user_t user_t:process signal;
Allow user_t self:process signal;
These two statements are in fact consistent, in fact self refers to the type of the target and the type of initiator is consistent
So you can't declare a type or property called Self

Allow user_t bin_t:file ~{write setattr ioctl};
Allows user_t to perform operations related to the bin_t type of file in addition to the write SetAttr IOCTL

Type_transition system Wifi_data_file:sock_file System_wpa_socket;
Type is switched to System_wpa_socket by default when a type is a category of system Wifi_data_file type Sock_file access

If the following statement wants to execute successfully
Type_transition init_t apache_exec_t:process apache_t;
At least first declare the following three rules:
Allow init_t Apache_exec_t:file execute;
Allow init_t apache_t:process transition;
Allow apache_t apache_exec_t:file entrypoint;

The syntax rules for type_transition and Type_change are the same, and the effect of type_change rules does not take effect in the kernel, but relies on user-space applications such as login or sshd

Introduction to SELinux rule analysis and syntax in Android