1# OpenHarmony SELinux Check 2 3## Introduction 4 5OpenHarmony provides a set of SELinux policy checks to complement the cases that may not be covered by the **neverallow** check and manual review. 6 7 8## Checking for Regular Expressions in Secondary Directories of /data in file_contexts 9 10### When to Use 11 12In 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. 13 14### Error Information 15 16The 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: 17```text 18Regex 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 19 There are two solutions: 20 1. Add '/data/log(/.*)?' to whitelist file 'data_regex_whitelist.txt' under 'base/security/selinux_adapter/sepolicy'; 21 2. Modify '/data/log(/.*)?' to remove the regular expression 22``` 23 24### Block Reason 25 26The regular expression **log(/.*)?** is detected in the secondary directory of **/data**. 27```text 28/data/log(/.*)? u:object_r:data_log:s0 29``` 30 31### Solution 32 33You can use either of the following methods to solve the problem: 34 35- Method 1: Add **/data/log/(.*)** to the **data_regex_whitelist.txt** file in the **//base/security/selinux_adapter/sepolicy/** directory.<br> 36 37 > **NOTE**<br>Before modifying the file, carefully review the modification to avoid security risks. 38 39- Method 2: Modify the regular expression. For example, modify the regular expression as follows: 40 ```text 41 /data/log u:object_r:data_log:s0 42 /data/log/(.*)? u:object_r:data_log:s0 43 ``` 44 45## Checking for Partition Labels in file_contexts 46 47### When to Use 48 49Partition labels are labels of the first-level directory under the root directory. Partition labels include the following: 50```text 51u:object_r:dev_file:s0 52u:object_r:etc_file:s0 53u:object_r:lib_file:s0 54u:object_r:config_file:s0 55u:object_r:updater_file:s0 56u:object_r:system_file:s0 57u:object_r:sys_prod_file:s0 58u:object_r:chip_prod_file:s0 59u:object_r:vendor_file:s0 60u:object_r:data_file:s0 61u:object_r:module_update_file:s0 62``` 63 64Avoid using partition labels for paths in **file_contexts**, which may pose security risks on subdirectories in the root directory. 65 66### Error Information 67 68The 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: 69 70``` 71partition 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 72 There are two solutions: 73 1. Add '/data/log u:object_r:data_file:s0' to whitelist file 'partition_label_use_whitelist.txt' under 'base/security/selinux_adapter/sepolicy'; 74 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'] 75``` 76 77### Block Reason 78 79The partition label **u:object_r:data_file:s0** is configured for **/data/log**. 80```text 81/data/log u:object_r:data_file:s0 82``` 83 84### Solution 85 86You can use either of the following methods to solve the problem: 87 88- Method 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. 89 90 > **NOTE**<br>Before modifying the file, carefully review the modification to avoid security risks. 91 92- Method 2: Modify the label of **/data/log**. For example, modify the label as follows: 93 ```text 94 /data/log u:object_r:data_log:s0 95 ``` 96 97## Checking for High-Risk Permission Groups 98 99### When to Use 100 101When 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. 102```json 103{ 104 "check_rules": [ 105 { 106 "name": "execute and execute_no_trans", 107 "description": "process label should transform while execute a file", 108 "perm_group": [ 109 { 110 "tclass": "*", 111 "perm": "execute execute_no_trans" 112 } 113 ] 114 } 115 ] 116} 117``` 118 119**check_rules** specifies all the check items. Each check item contains the following fields: 120 121- **name**: name of the check item. 122- **description**: description of the check item. 123- **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. 124 125### Error Information 126 127The 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: 128```text 129 check rule 'execute and execute_no_trans' in user mode failed, process label should transform while execute a file 130 violation list (scontext tcontext): 131 appspawn appspawn_exec 132 There are two solutions: 133 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' 134 2. Change the policy to avoid violating rule 'execute and execute_no_trans' 135 136 check rule 'execute and execute_no_trans' in developer mode failed, process label should transform while execute a file 137 violation list (scontext tcontext): 138 appspawn appspawn_exec 139 There are two solutions: 140 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' 141 4. Change the policy to avoid violating rule 'execute and execute_no_trans' 142``` 143 144### Block Reason 145 146The subject **appspawn** and the object **appspawn_exec** have permissions **execute** and **execute_no_trans** in the user version and developer mode policies. 147```text 148allow appspawn appspawn_exec:file { execute execute_no_trans }; 149``` 150 151### Solution 152 153You can use either of the following methods to solve the problem: 154 155- Method 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/**. 156 157 > **NOTE**<br>Before modifying the file, carefully review the modification to avoid security risks. 158 159 The following is an example of the file: 160 161 ```text 162 { 163 "whitelist": [ 164 { 165 "name": "execute and execute_no_trans", 166 "user": [ 167 "appspawn appspawn_exec" 168 ], 169 "developer": [ 170 ] 171 } 172 ] 173 } 174 ``` 175 176 **whitelist** specifies all the permission group check items that are allowed. Each item contains the following fields: 177 178 - **name**: name of the allowed check item, that is, the name of the check item. 179 - **user**: policy allowed for the user version. 180 - **developer**: policy allowed for the developer mode. 181 182 The following table provides the rules for determine where you should add the subject and object. 183 184 **Table 1** Rules for determining the entry of the subject and object 185 186 | Violate User Version Policy | Violate Developer Mode Policy | Entry Field | 187 | --------------------------- | ----------------------------- | ------------------------------------------------------------ | 188 | Yes | Yes | user | 189 | No | Yes | developer | 190 | Yes | No | user. In addition, delete the subject and object from the **developer** field. | 191 192- Method 2: Modify the policy to avoid the violation. 193 194### Deleting Redundant Policies from a Whitelist File 195 196If 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: 197```text 198 check rule 'execute and execute_no_trans' failed in whitelist file 'perm_group_whitelist.json' 199 remove the following unnecessary whitelists in rule 'execute and execute_no_trans' part 'user': 200 appspawn appspawn_exec 201 check rule 'execute and execute_no_trans' failed in whitelist file 'perm_group_whitelist.json' 202 remove the following unnecessary whitelists in rule 'execute and execute_no_trans' part 'developer': 203 appspawn appspawn_exec 204``` 205 206To 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: 207```text 208{ 209 "whitelist": [ 210 { 211 "name": "execute and execute_no_trans", 212 "user": [ 213 "appspawn appspawn_exec" 214 ], 215 "developer": [ 216 ] 217 } 218 ] 219} 220``` 221In the **perm_group_whitelist.json** file, locate **execute and execute_no_trans**, and delete **appspawn appspawn_exec** from the **user** field. 222 223**Table 2** Rules for deleting redundant policy from the whitelist file 224| User Version Whitelist Redundant | Developer Mode Whitelist Redundant | Field to Delete | 225| -------- | -------- | -------- | 226| Yes | Yes | user | 227| No | Yes | developer | 228| Yes | No | user | 229 230 231## Checking for Invalid Policy Baseline of Critical Processes 232 233### When to Use 234 235The 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: 236```text 237(allow sh vendor_file (dir (search))) 238 239developer_only(` 240(allow sh system_lib_file (dir (search))) 241') 242``` 243 244The policy enclosed in **developer_only** applies to the developer mode only. Other policies apply to both the user version and the developer mode. 245 246### Error Information 247 248The 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: 249```text 250 check 'sh' baseline in user mode failed 251 expect rule: (allow sh vendor_file (dir ())); actual rule: (allow sh vendor_file (dir (search))) 252 There are two solutions: 253 1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy' 254 2. Change the policy to satisfy expect rule 255 256 check 'sh' baseline in developer mode failed 257 expect rule: (allow sh vendor_file (dir ())); actual rule: (allow sh vendor_file (dir (search))) 258 There are two solutions: 259 1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy' and add developer_only 260 2. Change the policy to satisfy expect rule 261``` 262 263### Block Reason 264 265The 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 ()))**. 266 267### Solution 268 269You can use either of the following methods to solve the problem: 270 271- Method 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. 272 273 > **NOTE**<br>Before modifying the baseline file, carefully review the modification to avoid security risks. 274 275 The following table provides the rules for modifying the policy baseline. 276 277 **Table 3** Rules for modifying the policy baseline for critical processes 278 279 | User Version Baseline Error | Developer Mode Baseline Error | Update Policy in developer_only | 280 | -------- | -------- | -------- | 281 | Yes | Yes | No | 282 | No | Yes | Yes | 283 | Yes | No | Move the policy out of **developer_only**. | 284 285- Method 2: Modify the policy to avoid baseline violation. 286 287### Deleting Redundant Policies from a Baseline File 288 289If 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: 290``` 291 check 'sh' baseline in user mode failed 292 expect rule: (allow sh rootfs (dir (search))); actual rule: (allow sh rootfs (dir ())) 293 There are two solutions: 294 1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy' 295 2. Change the policy to satisfy expect rule 296 297 check 'sh' baseline in developer mode failed 298 expect rule: (allow sh rootfs (dir (search))); actual rule: (allow sh rootfs (dir ())) 299 There are two solutions: 300 1. Add the above actual rule to baseline file 'sh.baseline' under 'base/security/selinux_adapter/sepolicy' and add developer_only 301 2. Change the policy to satisfy expect rule 302``` 303 304Delete the policy from the baseline file, for example, **sh.baseline** in **//base/security/selinux_adapter/sepolicy/**. 305 306Delete 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. 307 308**Table 4** Rules for deleting redundant policies from the baseline file 309| User Version Baseline Redundant | Developer Mode Baseline Redundant | Field to Delete | 310| -------- | -------- | -------- | 311| Yes | Yes | Policy outside **developer_only** | 312| No | Yes | Policy in **developer_only** | 313| Yes | No | Policy outside **developer_only** | 314 315## Checking ioctl Permission Policies 316 317### When to Use 318 319For **ioctl**, you need to restrict **ioctlcmd** based on AVC logs in addition to configuring **allow** rules. Granting all permissions for **ioctlcmd** violates the least privilege principle. 320 321### Error Information 322 323The error "check ioctl rule in user mode failed." will be reported during the compilation if the **allow** rule contains the access permission to **ioctl** but the **ioctl** permissions are not restricted. 324```text 325 check ioctl rule in user mode failed. 326 violation list (allow scontext tcontext:tclass ioctl) 327 allow wifi_host data_service_el1_file:file ioctl; 328 allow wifi_host dev_hdfwifi:chr_file ioctl; 329 allow write_updater updater_block_file:blk_file ioctl; 330 please add "allowxperm" rule based on the above list. 331``` 332 333### Block Reason 334 335The **allow scontext tcontext:tclass ioctl** rule allows all **ioctl** permissions for **tcontext:tclass**, which violates the least privilege principle. Specific **allowxperm** rules need to be added to implement fine-grained control over the **ioctl** permissions. 336 337### Solution 338 339You can use either of the following methods to solve the problem: 340- Method 1: Restrict **ioctlcmd** of **ioctl** based on the AVC log. For example, the AVC log is as follows: 341 ```text 342 #avc: denied { ioctl } for pid=1 comm="init" path="/data/app/el1/bundle/public" dev="mmcblk0p11" ino=652804 ioctlcmd=0x6613 scontext=u:r:init:s0 tcontext=u:object_r:data_app_el1_file:s0 tclass=dir permissive=0 343 ``` 344 Based on the AVC log, set the SELinux policy as follows: 345 ```text 346 allow init data_app_el1_file:dir { ioctl }; 347 ``` 348 In addition, based on "ioctlcmd=0x6613" in the AVC log, add **allowxperm** to further restrict the **ioctl** permissions for the same user or developer mode. 349 ```text 350 allowxperm init data_app_el1_file:dir ioctl { 0x6613 }; 351 ``` 352 353- Method 2: Add "scontext tcontext tclass" to the **whitelist ioctl_xperm_whitelist.json** file in **//base/security/selinux_adapter/sepolicy/**. 354 355 > **NOTE**<br>Before modifying the whitelist file, carefully review the modification to avoid security risks. 356 357 In the AVC log, **user mode** indicates that the policy is the baseline shared by the user and developer modes, and **developer mode** indicates that the policy is used only as the baseline in developer mode and is added to the whitelist. 358 359 ```text 360 { 361 "whitelist": { 362 "user": [ 363 "wifi_host data_service_el1_file file" 364 ], 365 "developer": [ 366 ] 367 } 368 } 369 ``` 370 371 372## Checking Permissions on the Permissive Subject Type 373 374### When to Use 375 376The **permissive** subject type allows access to all objects, which violates the least privilege principle. 377 378### Error Information 379 380The error "check permissive rule in user mode failed." will be reported during the compilation if the policy file contains "permissive scontext;". 381```text 382 check permissive rule in user mode failed. 383 violation list (scontext): 384 sa_subsys_dfx_service 385 There are two solutions: 386 1. Add the above list to whitelist file 'permissive_whitelist.json' under 'base/security/selinux_adapter/sepolicy' in 'user' mode. 387 2. Change the policy to avoid violating rule. 388``` 389 390### Block Reason 391 392The rules contain new **permissive** subject type. 393 394### Solution 395 396You can use either of the following methods to solve the problem: 397- Method 1: Delete unnecessary **permissive** definitions. 398 399- Method 2: Add the subject type **scontext** to the **permissive_whitelist.json** file in **//base/security/selinux_adapter/sepolicy/**. 400 401 > **NOTE**<br>Before modifying the whitelist file, carefully review the modification to avoid security risks. 402 403 In the AVC log, **user mode** indicates that the policy is the baseline shared by the user and developer modes, and **developer mode** indicates that the policy is used only as the baseline in developer mode and is added to the whitelist. 404 405 ```text 406 { 407 "whitelist": { 408 "user": [ 409 "sa_subsys_dfx_service" 410 ], 411 "developer": [ 412 ] 413 } 414 } 415 ``` 416