目录
file_contexts新增标签
在file_contexts中新增标签的验证方式
在file_contexts中新增节点标签可能会遇到的问题
在file.te中一些常用的声明类型解释
在工作过程中,SElinux常用的有以下几个文件可用于新增标签
可用于加标签的文件名 | 含义 | 对应的声明文件名(一般会声明的地方,根本上放哪里都可以) |
---|---|---|
file_contexts | 给 文件/目录/节点 新增标签 | file.te |
genfs_contexts | 给节点新增标签,与上一个不同的是,不用执行restorecon操作 | file.te |
hwservice_contexts | 给hal服务新增标签 | hwservice.te |
property_contexts | 给属性新增标签 | property.te |
seapp_contexts | 给APP新增标签 | untrusted_app.te app.te...等等 |
service_contexts | 给系统服务新增标签 | service.te |
restorecon在Selinux中是一个非常常用的命令,其解释如下
"restorecon" 是一个用于恢复文件或目录的 SELinux 安全上下文的命令。在使用 SELinux(Security-Enhanced Linux)时,每个文件和目录都有一个安全上下文,它描述了文件或目录的安全属性和访问权限。如果由于某种原因安全上下文发生了改变,例如文件被移动或复制,可能导致安全上下文不一致。"restorecon" 命令可以用来重新设定文件或目录的安全上下文,以确保其符合预期的安全策略。
在通常情况下,你可以在终端中使用 "restorecon" 命令,语法如下:
restorecon (-Rv) /path/to/directory_or_file
其中:
-R
选项表示递归操作,将会对指定目录及其下所有子目录和文件进行恢复。-v
选项表示详细模式,将显示恢复过程中的详细信息。/path/to/directory_or_file
是要恢复安全上下文的目录或文件路径。请注意,在执行 "restorecon" 命令时,确保你具有足够的权限来操作目标文件或目录。此外,SELinux 的相关配置以及系统策略也会影响到 "restorecon" 命令的实际效果。
总之,"restorecon" 命令是用于恢复文件或目录的 SELinux 安全上下文,确保其符合系统的安全策略。
file_contexts新增标签
参考源码:file_contexts - OpenGrok cross reference for /system/sepolicy/private/file_contexts
可以看到dev的标签如下
/dev(/.*)? u:object_r:device:s0
这个含义代表/dev下所有的文件或者目录的标签都是device
可以通过ls -l -Z命令查看下标签,可以看到标签就是device
drwxr-xr-x 27 root root u:object_r:device:s0 3780 2024-02-21 11:21 dev
如果在dev的子目录下,创建一个目录或者文件,并不给它打标签的话,那么这个新创建的文件或者目录会和父目录的标签一致
cd dev
drwxrwxrwx 2 root root u:object_r:device:s0 40 2024-02-21 11:43 0
如果有单独打标签,则它的标签会是新打的标签
比如dev/block,它的标签打成这种/dev/block(/.*)? u:object_r:block_device:s0
那我们再查看它的标签,会发现标签是已经变了的
drwxr-xr-x 6 root root u:object_r:block_device:s0 3360 1970-01-01 00:06 block
在file_contexts中新增标签的验证方式
当新增文件标签时,有两种方式可以验证
编译方式 | 验证方法 |
整编 | 刷机烧录的方式,此方法不用任何别的操作,去你新增的标签下通过ls -l -Z查看即可看到效果 |
单编 | adb push完之后然后执行adb reboot 重启完成后去对应目录下去查看标签,会发现标签并没有生效 需要执行以下restorecon命令才可以 当文件对应路径下使用restorecon +文件名的方式,即可看到打标签后的效果 |
在file_contexts中新增节点标签可能会遇到的问题
请注意如果是新增的是设备节点,可能会出现标签无法生效的情况
因为在file_contexts中新增设备节点标签,是需要代码或者手动执行restorecon命令才会生效的,否则就是原来的标签,所以建议在genfs_contexts中去新增设备节点相关的标签。在genfs_contexts中新增设备节点的标签时,请注意需要把节点对应的超链接路径也新增上去才可以,这种带->的就是超链接,对于这种情况就需要当前目录/sys/bus/platform/devices/soc:wsa_spkr_en1_pinctrl 以及对应的超链接目录/sys/bus/platform/drivers/msm-cdc-pinctrl都添加上才可以,具体加法,后面出一节关于genfs_contexts再进行分析。
/sys/bus/platform/devices/soc:wsa_spkr_en1_pinctrl # ls -l
total 0
lrwxrwxrwx 1 root root 0 2024-02-21 12:05 driver -> ../../../../bus/platform/drivers/msm-cdc-pinctrl
在file.te中一些常用的声明类型解释
这种代表系统节点声明,一般是驱动加载后创建的系统节点
type sysfs_uio, sysfs_type, fs_type;
这种是可执行文件的type声明,并且这个可执行文件在system侧
type tcpdump_exec, system_file_type, exec_type, file_type;
这种是普通非可执行文件的type声明,并且这个文件在system侧
type mac_perms_file, system_file_type, file_type;
这种不声明它属于system和vendor,就没有system和vendor的neverallow限制
type hostapd_data_file, file_type, data_file_type;
这种是普通非可执行文件的type声明,并且这个文件在vendor侧
type vendor_hal_file, vendor_file_type, file_type;
这种是可执行文件的type声明,并且这个可执行文件在vendor侧
type hal_configstore_default_exec, exec_type, vendor_file_type, file_type;
这种代表是proc节点的声明
type proc_cmdline, fs_type, proc_type;
这种代表是文件类型,并且是core_data_file_type的
type adb_data_file, file_type, data_file_type, core_data_file_type;
还有一些带有mlstrustedobject的type,这种type在充当客体时可以越过MLS检查,
声明的时候带有core_data_file_type,会有很多neverallow限制,这种的domain域的基本上都不能与它通信