OpenHarmony SELinux Check

Introduction

OpenHarmony provides a set of SELinux policy checks to complement the cases that may not be covered by the neverallow check and manual review.

Checking for Regular Expressions in Secondary Directories of /data in file_contexts

When to Use

In the /data partition, there are a large number of application files and user files. Frequent access to these files may cause fragmentation. However, labelling the files may comprise system performance. To solve this problem, the secondary directories under /data cannot contain regular expressions. The check scans the file_contexts file to check for regular expressions.

Error Information

The error "Regex is not allowed in the secondary directory under data" will be reported during the compilation if any regular expression is found in the secondary directories of /data in file_contexts. The error information is as follows:

Regex is not allowed in the secondary directory under data, check '/data/log(/.*)?' failed in file out/rk3568/obj/base/security/selinux_adapter/file_contexts:214
 There are two solutions:
 1. Add '/data/log(/.*)?' to whitelist file 'data_regex_whitelist.txt' under 'base/security/selinux_adapter/sepolicy';
 2. Modify '/data/log(/.*)?' to remove the regular expression

Block Reason

The regular expression log(/.*)? is detected in the secondary directory of /data.

/data/log(/.*)?                 u:object_r:data_log:s0

Solution

You can use either of the following methods to solve the problem:

1. Add /data/log/(.*) to the data_regex_whitelist.txt file in the //base/security/selinux_adapter/sepolicy/ directory.

   NOTE
   Before modifying the file, carefully review the modification to avoid security risks.

2. Modify the regular expression. For example, modify the regular expression as follows:

   /data/log                       u:object_r:data_log:s0
   /data/log/(.*)?                 u:object_r:data_log:s0
   

Checking for Partition Labels in file_contexts

When to Use

Partition labels are labels of the first-level directory under the root directory. Partition labels include the following:

u:object_r:dev_file:s0
u:object_r:etc_file:s0
u:object_r:lib_file:s0
u:object_r:config_file:s0
u:object_r:updater_file:s0
u:object_r:system_file:s0
u:object_r:sys_prod_file:s0
u:object_r:chip_prod_file:s0
u:object_r:vendor_file:s0
u:object_r:data_file:s0
u:object_r:module_update_file:s0

Avoid using partition labels for paths in file_contexts, which may pose security risks on subdirectories in the root directory.

Error Information

The error "partition label is not allow to use" will be reported during the compilation if improper use of partition labels is found in file_contexts. The error information is as follows:

partition label is not allow to use, check '/data/log u:object_r:data_file:s0' failed in file out/rk3568/obj/base/security/selinux_adapter/file_contexts:213
 There are two solutions:
 1. Add '/data/log u:object_r:data_file:s0' to whitelist file 'partition_label_use_whitelist.txt' under 'base/security/selinux_adapter/sepolicy';
 2. Change '/data/log u:object_r:data_file:s0' to avoid using label in ['u:object_r:dev_file:s0', 'u:object_r:etc_file:s0', 'u:object_r:lib_file:s0', 'u:object_r:config_file:s0', 'u:object_r:updater_file:s0', 'u:object_r:system_file:s0', 'u:object_r:sys_prod_file:s0', 'u:object_r:chip_prod_file:s0', 'u:object_r:vendor_file:s0', 'u:object_r:data_file:s0', 'u:object_r:module_update_file:s0']

Block Reason

The partition label u:object_r:data_file:s0 is configured for /data/log.

/data/log   u:object_r:data_file:s0

Solution

You can use either of the following methods to solve the problem:

1. Add the path and label /data/log u:object_r:data_file:s0 to the partition_label_use_whitelist.txt file in the //base/security/selinux_adapter/sepolicy/ directory.

   NOTE
   Before modifying the file, carefully review the modification to avoid security risks.

2. Modify the label of /data/log. For example, modify the label as follows:

   /data/log    u:object_r:data_log:s0
   

Checking for High-Risk Permission Groups

When to Use

When a pair of subject and object have different SELinux permissions, an attack path may be formed. This check is used to check user version policies and developer mode policies. The check items are configured in the base/security/selinux_adapter/scripts/selinux_check/config/perm_group.json file.

{
    "check_rules": [
        {
            "name": "execute and execute_no_trans",
            "description": "process label should transform while execute a file",
            "perm_group": [
                {
                    "tclass": "*",
                    "perm": "execute execute_no_trans"
                }
            ]
        }
    ]
}

check_rules specifies all the check items. Each check item contains the following fields:

• name: name of the check item.
• description: description of the check item.
• perm_group: list of permissions to check. perm_group consists of tclass and perm. tclass specifies the type of the object to access. If it is set to *****, it indicates all types. perm specifies the permission of the operation.

Error Information

The error "check rule 'xxx' in user mode failed" will be reported during the compilation if incorrect permission configuration is found. 'xxx' indicates the name of the check item. The error information is as follows:

        check rule 'execute and execute_no_trans' in user mode failed, process label should transform while execute a file
        violation list (scontext tcontext):
                appspawn appspawn_exec
        There are two solutions:
        1. Add the above list to whitelist file 'perm_group_whitelist.json' under 'base/security/selinux_adapter/sepolicy' in 'user' part of 'execute and execute_no_trans'
        2. Change the policy to avoid violating rule 'execute and execute_no_trans'

        check rule 'execute and execute_no_trans' in developer mode failed, process label should transform while execute a file
        violation list (scontext tcontext):
                appspawn appspawn_exec
        There are two solutions:
        3. Add the above list to whitelist file 'perm_group_whitelist.json' under 'base/security/selinux_adapter/sepolicy' in 'developer' part of 'execute and execute_no_trans'
        4. Change the policy to avoid violating rule 'execute and execute_no_trans'

Block Reason

The subject appspawn and the object appspawn_exec have permissions execute and execute_no_trans in the user version and developer mode policies.

allow appspawn appspawn_exec:file { execute execute_no_trans };

Solution

You can use either of the following methods to solve the problem:

1. Add the subject and object to the user or developer field in the perm_group_whitelist.json file in //base/security/selinux_adapter/sepolicy/.

   NOTE
   Before modifying the file, carefully review the modification to avoid security risks.
   The following is an example of the file:

   {
       "whitelist": [
           {
               "name": "execute and execute_no_trans",
               "user": [
                   "appspawn appspawn_exec"
               ],
               "developer": [
               ]
           }
       ]
   

} ``` whitelist specifies all the permission group check items that are allowed. Each item contains the following fields:

- **name**: name of the allowed check item, that is, the name of the check item.
- **user**: policy allowed for the user version.
- **developer**: policy allowed for the developer mode. 

The following table provides the rules for determine where you should add the subject and object.

**Table 1** Rules for determining the entry of the subject and object

2. Modify the policy to avoid the violation.

Deleting Redundant Policies from a Whitelist File

If the whitelist file still contains the policy that has been deleted, the error "remove the following unnecessary whitelists in rule 'xxx' part 'user'" will be reported in the compilation. 'xxx' indicates the name of the check item intercepted. The error information is as follows:

        check rule 'execute and execute_no_trans' failed in whitelist file 'perm_group_whitelist.json'
        remove the following unnecessary whitelists in rule 'execute and execute_no_trans' part 'user':
                appspawn appspawn_exec
        check rule 'execute and execute_no_trans' failed in whitelist file 'perm_group_whitelist.json'
        remove the following unnecessary whitelists in rule 'execute and execute_no_trans' part 'developer':
                appspawn appspawn_exec

To solve the problem, you need to delete the redundant policy from the perm_group_whitelist.json file in //base/security/selinux_adapter/sepolicy/. The following is an example of the file:

{
    "whitelist": [
        {
            "name": "execute and execute_no_trans",
            "user": [
                "appspawn appspawn_exec"
            ],
            "developer": [
            ]
        }
    ]
}

In the perm_group_whitelist.json file, locate execute and execute_no_trans, and delete appspawn appspawn_exec from the user field.

Table 2 Rules for deleting redundant policy from the whitelist file

Checking for Invalid Policy Baseline of Critical Processes

When to Use

The SELinux policies of OpenHarmony critical processes, such as shell and console, must be protected against unauthorized deletion and addition, which may cause system unavailability or security risks. The baseline policies of the critical process xx are defined in the xx**.baseline** file in //base/security/selinux_adapter/sepolicy/. The following is an example of the sh (SElinux label) baseline:

(allow sh vendor_file (dir (search)))

developer_only(`
(allow sh system_lib_file (dir (search)))
')

The policy enclosed in developer_only applies to the developer mode only. Other policies apply to both the user version and the developer mode.

Error Information

The error "check 'xxx' baseline in user mode failed" will be reported in the compilation if a policy is added or deleted for a critical process. 'xxx' indicates the SELinux label of the process. The error information is as follows:

        check 'sh' baseline in user mode failed
                expect rule: (allow sh vendor_file (dir ())); actual rule: (allow sh vendor_file (dir (search)))
        There are two solutions:
        1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy'
        2. Change the policy to satisfy expect rule

        check 'sh' baseline in developer mode failed
                expect rule: (allow sh vendor_file (dir ())); actual rule: (allow sh vendor_file (dir (search)))
        There are two solutions:
        1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy' and add developer_only
        2. Change the policy to satisfy expect rule

Block Reason

The policy allow sh vendor_file:dir search;, that is, (allow sh vendor_file (dir (search))) in the CIL format, is added for the shell process (labelled sh), which violates the process baseline for the user version and developer mode. The expected baseline in the CIL format is (allow sh vendor_file (dir ())).

Solution

You can use either of the following methods to solve the problem:

1. Add the policy (in the CLI format) indicated by actual rule in the error message to the baseline file xx.baseline in //base/security/selinux_adapter/sepolicy/ as a new baseline. In the file name, xx indicates the process label.

   NOTE
   Before modifying the baseline file, carefully review the modification to avoid security risks. The following table provides the rules for modifying the policy baseline.

   Table 3 Rules for modifying the policy baseline for critical processes

2. Modify the policy to avoid baseline violation.

Deleting Redundant Policies from a Baseline File

If the baseline file still contains the policy that has been deleted, the error "check 'xx' baseline in user mode failed" will be reported in the compilation. 'xx' indicates the process label intercepted. The error information is as follows:

        check 'sh' baseline in user mode failed
                expect rule: (allow sh rootfs (dir (search))); actual rule: (allow sh rootfs (dir ()))
        There are two solutions:
        1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy'
        2. Change the policy to satisfy expect rule

        check 'sh' baseline in developer mode failed
                expect rule: (allow sh rootfs (dir (search))); actual rule: (allow sh rootfs (dir ()))
        There are two solutions:
        1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy' and add developer_only
        2. Change the policy to satisfy expect rule

Delete the policy from the baseline file, for example, sh.baseline in //base/security/selinux_adapter/sepolicy/.

Delete the redundant policy, for example, (allow sh rootfs (dir (search))), and ensure that the actual policy is the same as the expected one. The following table provides the rules for deleting redundant policies from the baseline file.

Table 4 Rules for deleting redundant policies from the baseline file