OpenHarmony中SELinux使用详解

目录

• 1.SELinux简介
• 2.SELinux概念
• 3.SELinux模式
• 4.OH中SELinux使用详解
• 5.OH中SELinux报错分析
  5.1 日志错误问题分析
  5.2 新增节点权限问题
  5.3 新增服务权限问题

1.SELinux简介

SELinux是Security Enhanced Linux 的缩写，也就是安全强化的 Linux，旨在增强传统Linux操作系统的安全性，解决传统Linux系统中自主访问控制（DAC）系统中的各种权限问题（如root权限过高等）。这里举一个例子便于理解，假设系统中某个服务进程出现了一个漏洞，使得某个远程用户可以访问系统的敏感文件（如/etc/dev）。如果我们的Linux系统启用了SELinux，而查询SELinux策略得知，这个服务进程并不具备访问敏感文件（/etc/dev）的权限，所以这个远程用户通过这个进程访问敏感文件(/etc/dev)就会被SELinux所阻挡，起到保护Linux系统的作用。

2. SELinux基本概念

Linux操作系统的安全机制其实就是对两样东西做限制：进程和系统资源（文件、socket等）。linux操作系统是通过用户和组的概念来对我们的系统资源进行限制，每个进程都需要一个用户才能执行。在SELinux当中针对这两样东西定义了两个基本概念：域（domin）和上下文（context）。

我们可以通过ps -Z 命令来查看当前进程的域信息，也就是进程的SELinux信息：
**# ps -Z
LABEL PID TTY TIME CMD
u:r:sh:s0 10466 pts/1 00:00:00 sh
u:r:sh:s0 10468 pts/1 00:00:00 ps

通过ls -Z 命令，我们可以查看文件上下文信息，也就是文件的SELinux信息：
**# ls -Z
u:object_r:system_bin_file:s0 bin
u:object_r:rootfs:s0 chip_prod
u:object_r:vendor_file:s0 chipset
u:object_r:configfs:s0 config
u:object_r:data_file:s0 data
u:object_r:dev_file:s0 dev
u:object_r:system_etc_file:s0 etc
u:object_r:init_exec:s0 init
u:object_r:system_lib_file:s0 lib

3.SELinux的工作模式

下面通过这个图来说明，SELinux工作流程

可以从图中看出，需要关注的关键信息如下:
1)主体（Subject）：指主动对其它实体施加动作的实体，例如进程、服务等。
2)策略（policy）：权限策略，通过在te文件中配置对应的权限语句实现，权限策略以type或attribute作为执行对象。
3)安全上下文（Security Context）：实际上就是一个附加在主体或客体上的标签。
4)目标（Object）：是被动接受其他实体访问的实体，例如文件、系统属性等。

SELinxu工作的核心就是安全上下文。安全上下文是一组和进程或对象有关的安全属性，每一个进程或对象都会记录一条安全上下文，将其作为SELinux判断进程是否能读取对象的依据。安全上下文分为“进程安全上下文”和“文件安全上下文”。一个“进程安全上下文”一般对应多个“文件安全上下文”。
只有两者的安全上下文对应上了，进程才能访问文件。它们的对应关系由策略中的规则决定。
文件安全上下文由文件创建的位置和创建文件的进程所决定。而且系统有一套默认值，用户也可以对默认值进行设定。需要注意的是，单纯的移动文件操作并不会改变文件的安全上下文。
SELinux有3种工作模式：
【enforcing】强制模式。违反 SELinux 规则的行为将被阻止并记录到日志中。
【permissive】宽容模式。违反 SELinux 规则的行为只会记录到日志中。一般为调试用。
【disabled】关闭 SELinux。
模式之间的临时切换，如需（【disabled】关闭）永久有效，还需要修改配置文件。

**# getenforce // 查看SELinux状态
Enforcing
**# setenforce 0 // 设置SELinux状态为宽容模式
**# getenforce
Permissive
**# setenforce 1 // 设置SELinux状态为强制模式
**# getenforce
Enforcing

4.OH中SELinux使用详解

SELinux在OH中应用整体来说，功能和以上介绍的使用方法并无太大差别，只是在原生SELinux内核中做了部分驱动和文件系统的适配。目前码云社区上master分支以RK3568为例子做了适配并开启了SELinux，其他型号的设备需要自己做适配。
OpenHarmony SELinux的主代码仓：
https://gitee.com/openharmony/security_selinux_adapter

SELinux结构图：

SELinux运行视图：

在OH源码根目录下third_party\selinux是原生的代码：
在base\security\selinux_adapter是OH封装对外提供的接口源码：
OpenHarmony的通用sepolicy策略文件，存放到base\security\selinux_adapter\sepolicy目录下。
OpenHarmony中SELinux详情介绍：
https://gitee.com/openharmony/security_selinux_adapter/blob/master/README.md

OpenHarmony中SELinux配置指导：
https://gitee.com/dapaodexiaoyu2/binary_keep/blob/master/OH_Selinux%E9%85%8D%E7%BD%AE%E8%AF%B4%E6%98%8E.docx
OpenHarmony中提供的selinux规则配置工具：
https://gitee.com/steven-q/selinux_guide?_from=gitee_search
OpenHarmony中SELinux其他相关文档：
https://gitee.com/cc_ggboy/binary_keep
OH中SELinux调式方法
1） 文件标签查看方法：

HWTAS:/ # ls -lZ

ls -lZ

total 260

drwxr-xr-x 1 root root u:object_r:radio_data_file:s0 27 2018-08-08 00:01 3rdmodem

drwxr-xr-x 1 root root u:object_r:radio_data_file:s0 27 2018-08-08 00:01 3rdmodemnvm

drwxr-xr-x 1 root root u:object_r:radio_data_file:s0 27 2018-08-08 00:01 3rdmodemnvmbkp

dr-xr-xr-x 137 root root u:object_r:cgroup:s0 0 2021-12-02 02:28 acct

drwxr-xr-x 16 root root u:object_r:apex_mnt_dir:s0 320 2021-12-02 02:28 apex

lrw-r--r-- 1 root root u:object_r:rootfs:s0 11 2018-08-08 00:01 bin -> /system/bin

如果查询到文件的标签是unlabel，则说明该文件未定义标签，需要给它打上标签。

2） 进程标签查看方法：

HWTAS:/ # ps -AZ

ps -AZ

u:r:system_app:s0 system 2573 706 6601072 137968 SyS_epoll_wait 0 S com.huawei.systemmanager:service

u:r:system_app:s0 system 2854 706 6512920 114972 SyS_epoll_wait 0 S com.huawei.iaware

u:r:system_app:s0 system 3015 706 7097144 118460 SyS_epoll_wait 0 S com.huawei.systemserver

u:r:platform_app:s0:c512,c768 u0_a93 3171 706 8739312 67936 SyS_epoll_wait 0 S com.huawei.android.launcher

u:r:system_app:s0 system 3387 706 7398984 102188 SyS_epoll_wait 0 S com.huawei.nearby

u:r:system_app:s0 system 3512 706 6999352 116348 SyS_epoll_wait 0 S com.huawei.harmonyos.foundation

u:r:system_app:s0 system 3553 706 7193684 123272 SyS_epoll_wait 0 S com.huawei.HwOPServer

u:r:system_app:s0 system 3577 706 6263956 120380 SyS_epoll_wait 0 S com.huawei.hiview

u:r:system_app:s0 system 3602 707 1703196 62728 SyS_epoll_wait 0 S com.huawei.security2
查看自己的进程标签： ps –AZ | grep 进程名字，如果进程的标签是limit_domain则需要给进程打上自己的标签。

oh中，也可以通过shell命令查看SELinux的日志。
在hdc shell中执行如下的命令
dmesg | grep avc:
会有类似这样的一条条输出
[10125.592956] [pid:59,cpu2,kauditd,3]audit: type=1400 audit(68010562.527:86963): avc: denied { read } for pid=1317 comm="hiview" name="diskstats" dev="proc" ino=4026532509 scontext=u:r:hiview:s0 tcontext=u:object_r:proc_diskstats_file:s0 tclass=file permissive=1

5.OH中SELinux报错分析

5.1 日志错误问题分析

报错1：
StateSenseThrea: type=1400 audit(0.0:371): avc: denied { read write } for pid=2572 name="mlpshub" dev="tmpfs" ino=4684 scontext=u:r:system_app:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
以下是此拒绝事件的关键元素：
{ read write } 是具体操作 - 试图进行的操作会使用括号突出显示：这里代表进行读/写操作。
操作方 - scontext（来源上下文）条目表示操作方；在此例中为 system_app 操作进程。
对象 - tcontext（目标上下文）条目表示对哪个对象执行操作；在此例中为 device。
结果 - tclass（目标类别）条目表示操作对象的类型；在此例中为 chr_file（字符设备）。
name-节点名称
错误解析：system_app进程对mlpshub这个节点进行读/写device域的 chr_file字节文件权限被拒绝访问。

报错2：
E SELinux : avc: denied { find } for service=MlpsService pid=1134 uid=0 scontext=u:r:logserver:s0 tcontext=u:object_r:MlpsService:s0 tclass=service_manager permissive=0
错误解析：logserver进程查找MlpsService域的 service_manager权限被拒绝访问。

报错3：
E selinux_dmd: avc: denied { open } for dsm=hisi_Q pid=1097 comm="Mlps" path="/dev/mlpshub" dev="tmpfs" ino=14293 scontext=u:r:hwpged:s0 tcontext=u:object_r:mlpshub_device:s0 tclass=chr_file permissive=0 CMD=/system/bin/hwpged
错误解析：hwpged进程打开mlpshub_device节点chr_file字节文件权限被拒绝访问。

一般问题问题解决方案，在对应的te文件中加入如下格式的allow
allow scontext tcontext:tclass { 操作 }

5.2 新增节点权限问题

报错
StateSenseThrea: type=1400 audit(0.0:371): avc: denied { read write } for pid=2572 name="mlpshub" dev="tmpfs" ino=4684 scontext=u:r:system_app:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
错误解析：system_app进程对mlpshub这个节点进行读/写device域的 chr_file字节文件权限被拒绝访问。
查询材料后应该在对应的system_app.te中加入allow操作
allow system_app device:chr_file { read write }
添加后发现未生效， 还是报权限错误，此时进一步思考和查看发现google为了安全，限制了一部分权限，在system/sepolicy/public/domain.te中可以看到很多neverallow规则：

最终解决方案：将新增节点定义为新的device类型

1、在device.te中新增mlpshub_device定义：

type mlpshub_device, dev_type;

2、在file_contexts中指定或者修改标签：

/dev/mlpshub u:object_r:mlpshub_device:s0

3、在system_app.te中添加allow权限：

allow system_app device:chr_file { read write }

4、在sepolicy/selinux_check仓中加入白名单校验

4.1、white_list/raw_type_cross_access.txt 中加入

allow system_app mlpshub_device:chr_file { ioctl open read write };

4.2 white_list/rule_white_list.txt中加入

allow,system_app,mlpshub_device,chr_file, read write open ioctl
allow,init,mlpshub_device,chr_file, setattr
allow,vendor_init,mlpshub_device,chr_file, setattr

5.3 新增服务权限问题

报错：

E SELinux : avc: denied { find } for service=MlpsService pid=1134 uid=0 scontext=u:r:logserver:s0 tcontext=u:object_r:MlpsService:s0 tclass=service_manager permissive=0

错误解析：logserver进程查找MlpsService域的 service_manager权限被拒绝访问。

查询材料后应该在对应的system_server.te中加入allow操作

allow logserver MlpsService:service_manager { find };

添加后发现未生效， 还是报权限错误，此时进一步查看发现原因是未提前定义MlpsService

最终解决方案：将新增定义MlpsService

1、在 service.te中新增MlpsService定义：

type MlpsService, service_manager_type;

2、在service_contexts中指定或者修改标签：

MlpsService u:object_r:MlpsService:s0

3、在system_server.te中添加allow权限：

allow logserver MlpsService:service_manager { find };

4、在sepolicy/selinux_check仓中加入白名单校验

4.1、white_list/raw_type_cross_access.txt 中加入

allow logserver MlpsService:service_manager { find };