Android SELinux 参数语法介绍及基础分析

本文深入解析SEAndroid安全策略,涵盖安全上下文、Type Enforcement机制、SELinux策略文件及权限配置等内容,助您全面掌握Android系统安全。

Android SELinux安全策略主要使用对象安全上下文的基础进行描述,通过主体和客体的安全上下文去定义主体是否有权限访问客体,称为TypeEnforcement

安全上下文(Security Context)

SEAndroid中的安全上下文:共有4个部分组成分别为user、role、type、sensitivity level

u:object_r:system_data_file:s0为例
user:安全上下文的第一列为user,在SEAndroid中的user只有一个就是u。
role:第二列表示role,在SEAndroid中的role有两个,分别为r和object_r。
type:第三列为type,SEAndroid中共定义了139种不同的type。
security level:第四列是专为MLS访问机制所添加的安全上下文的扩展部分,
格式为sensitivity[:category list][- sensitivity[:category list]],例如s0 - s15:c0.c1023,
其中s0之后的内容可以不需要,冒号后面的内容是category,sensitivity和category组合一起声明了当前的安全级别(security level),“-”号左右分别标识了安全级别的最低和最高,这一列的参数将在MLS约束检查时用到,“15”、“1023”表示了sensitivity和category的最大值,这一参数可在Android.mk中定义。

安全上下文中最重要的部分就是第三列的type了,对于进程type被称为domain,type是整个SEAndroid中最重要的一个参量,所有的policy都围绕这一参量展开,所以为系统中每个文件标记上合适的type就显得极为重要了。在SEAndroid中关于安全上下文配置的核心文件主要是file_contexts、seapp_contexts和property_contexts 文件。

sContext相关文件表示的上下文
file_contexts系统中所有file_contexts安全上下文
seapp_contextsapp安全上下文
property_contexts属性的安全上下文
service_contextsservice文件安全上下文
genfs_contexts虚拟文件系统安全上下文
类型强制TE(Type Enforcement)

TE强制访问方式是SEAndroid中的最主要的安全手段,所有关于TE的强制访问规则都被定义在了后缀为te的文件中

在te文件中基本能总结为完成如下操作:
(1)对type类型的定义和将type归到相应的attribute中
SEAndroid在te文件中定义了安全策略中最基本的参量type,同时将具有共性的type归在一起构成一个称为attribute的集合,policy的规则执行也能以attribute作为执行对象。
(2)通过allow语句制定主体客体强制访问规则(白名单规则,不再规则中的都默认为非法操作)
(3)通过type_transition语句制定tpye类型转换规则
(4)通过dontaudit语句声明对一些被安全策略拒绝的访问不再进行审核。
审核是对于发生了访问违规或出现了被系统安全规则拒绝的行为进行日志记录的过程,审核可以帮助系统管理员发现bug和可能的入侵尝试。
默认情况下,SEAndroid会记录被拒绝的访问检查,但策略语言dontaudit允许我们取消这些默认的预料之中的拒绝审核消息。

  • SEAndroid为所有type共定义了17个attribute:
attribute含义
dev_type:包含了所有关于设备的type
domain:包含了如下所列的所有关于进程的type,通常策略中的访问主体也就是进程所在的domain都包含在了这一attribute中。
fs_type:包含了所有与文件系统相关的type。如下所列,大多是虚拟文件系统。
file_type:包含了所有存在于非伪文件系统的相关文件的type,数量过多不再列举。
exec_type:包含了所有关于domian接入点的type,多被用在domain transition中
data_file_type:包含了所有在/data目录下的文件type
sysfs_type:包含了在sysfs文件系统下的所有文件的type,在SEAndroid中只有sysfs_writable包含在这个attribute中。
node_type:所有与nodes/hosts有关的type,在SEAndroid中只有node包含在这个attribute中。
netif_type:
port_type:包含了所有与网络端口相关的type,在SEAndroid中只有port包含在这个attribute中。包含了所有与网络接口相关的type,在SEAndroid中只有netif包含在这个attribute中。
mlstrustedsubject:包含了所有能越过MLS检查的主体domain。
mlstrustedobject:包含了所有能越过MLS检查的客体type。
unconfineddomain:包含了所有拥有无限权限的type。
appdomain:包含了所有与app相关的type
netdomain:包含了所有与需要访问网络的app相关的type
bluetoothdomain:包含了所有与需要访问bluetooth的app相关的type
binderservicedomain:包含了所有与binder服务相关的type

SEAndroid中共定义了三个拥有巨大权限的attribute,分别是mlstrustedsubject、mlstrustedobject、unconfineddomain
mlstrustedsubject的type:在充当主体domain是可以越过MLS检查,
mlstrustedobject的type:在充当客体时可以越过MLS检查,
unconfineddomain的type:则拥有所有权限可对客体进行任意操作。

  • SEAndroid为系统定义了33个te策略文件,这33个策略文件是:

adbd.te、file.te、su.te、app.te、gpsd.te、netd.te、system.te、bluetoothd.te、init.te、net.te、ueventd.te、bluetooth.te、installd.te、nfc.te、unconfined.te、cts.te、kernel.te、qemud.te、vold.te、dbusd.te、keystore.te、radio.te、wpa_supplicant.te、debuggerd.te、mediaserver.te、rild.te、zygote.te、device.te、servicemanager.te、domain.te、shell.te、drmserver.te、surfaceflinger.te

TE一般放在device/qcom/sepolicy/system/sepolicy中,所有.te后缀的文件通过编译之后,都会生成一个sepolicy文件

常见te含义
file.te针对属性file的策略
init.te在这一文件中声明了init拥有无限权限
rild.te针对daemon domain的策略
system.te这一文件主要针对的是系统app和system server进程。对系统app访问binder、systemdata files、dalvikcatch、keystone等进行权限控制,对system server访问网络、bluetooth、netlink、app、binder、device、data files、socket、cache files等进行权限控制
app.te在这一文件里将安装在系统上的第三方app分类为受信任的app和不受信任的app,分别用不同的type表示,再分别为这两种app在访问网络,bluetooth,sdcard,数据,缓存,binder等等名感位置时设置相应权限
AVC LOG的抓取

1.提取所有的avc
adb shell “cat /proc/kmsg | grep avc” > avc_log.txt
或者
logcat -b events | grep avc

2.使用 audit2allow tool 直接生成policy
sudo apt install policycoreutils
audit2allow -i avc_log.txt 即可自动输出生成的policy

selinux权限添加相关: 将所有avc相关log拷贝到avc.txt中,将avc.txt拷贝到相关项目根目录下,执行 audit2allow -i avc.txt 会生成相应的权限语句;

3.查看安全上下文scontext:属于什么te
查看进程(APP):ps -Z
查看文件:ls -Z

AVC LOG分析
  • 示例:
I auditd  : type=1400 audit(0.0:4720): avc: denied { write } for comm="sh" name="export" dev="sysfs" ino=10547 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0
  • avc参数分析:

denied后面{}里的是要执行的动作,比如append,open,execmod,link等等
scontext指的是域,对应的是te文件 上面报错这条对应te文件是untrusted_app.te,scontext全写是source_type context;
tcontext指的是目标类型,上面报错这条对应的是目标类型system_file,tcontext全写是target_type context;
tclass指的是类别,上面报错这条对应的是类别是file

  • 添加对应TE
allow untrusted_app sysfs:file write;

TE表达式格式:
rule_name:规则名称,除了有allow还有dontaudit,auditallow和neverallow
source_type:源类型,对应一个很重要的概念--------域(domain)
tartget_type:目标的类型,即安全上下文,SELinux一个重要的判断对象
class:类别,目标(客体)是哪种类别,主要有File,Dir,Socket,SEAndroid还有Binder等,在这些基础上又细分出设备字符类型(chr_file),链接文件(lnk_file)等。可以通过ls -l查看文件类型
perm_set:动作集

  • 验证

重新编译bootimage:make bootimage

相关示例
  • SEAndroid为APP层读写sys设备节点自定义类型开放访问权限方法(如:sys/class/leds/red_aux/brightness)

1.添加设备节点读写权限

system/core/rootdir/init.rc

//开放节点让系统进程可以访问
chown system system /sys/class/leds/red_aux/brightness
//修改设备节点可读可写
chmod 0666 /sys/class/leds/red_aux/brightness

2.修改file.te,加入类型声明,定义selinux type

device/qcom/sepolicy/common/file.te

//表示sysfs_ledred_leds 节点具有fs_type和sysfs_type属性
type sysfs_ledred_leds, fs_type, sysfs_type;

3.修改file_contexts

device/qcom/sepolicy/common/file_contexts

//绑定sysfs_ledred_leds到对应的实际节点
/sys/devices/soc/75b5000.i2c/i2c-7/7-0045/leds/red_aux/brightness u:object_r:sysfs_ledred_leds:s0

4.修改sysetem_app.te文件,加入权限声明

device/qcom/sepolicy/common/file_contexts

//表示允许system_app进程能够拥有对sysfs_ledred_leds的这个字符设备的读写权限,rw_file_perms代表读写权限
allow system_app sysfs_ledred_leds:file rw_file_perms;

注意:以上的sysfs_ledred_leds必须与file.te文件中声明的文件类型、名称必须一致

5.APP需配置为系统APP
在AndroidMainefest.xml中配置android:sharedUserId="android.uid.system"

  • 新增allow xxx权限,编译报错neverallow的处理方式示例

allow radio vendor_data_file:file { read };在这里插入图片描述

  1. 国内版本可适当注释掉原生相关neverallow进行规避,不推荐方式

根据报错信息 在918行 system/sepolicy/public/domain.te加上 -radio

  1. CTS版本不能有任何neverallow,只能去掉添加的权限,自定义类型,绕过neverallow限制,推荐方式
这是因为我们添加的SELinux权限违反了google的neverallow规则,google不允许名为radio源类型访问标签名为vendor_data_file的目标类型,

解决方案是修改我们要访问的文件的标签名vendor_data_file,如何修改呢?我们要访问的目录是/data/vendor/time_code/,先看一下这个目录的信息
ls -Z data/vendor/time_code/

需要修改的标签属于文件类型,另外还有属性类型和程序类型,对于文件类型标签的修改就是自定义一个新的标签,在file.te中定义,在file_contexts中使用

file.te中添加如下语句:
type tct_time_data_file, file_type, data_file_type, mlstrustedobject;
file_contexts中添加如下语句:
/data/vendor/time_code(/.*)?       u:object_r:tct_time_data_file:s0

标签就被修改为了tct_time_data_file,然后再修改radio.te中的目标类型
allow radio tct_time_data_file:dir rw_dir_perms;

再进行编译
相关拓展
  • 常用文件

属性相关:property.te property_contexts
文件相关:file.te file_contexts
第三方应用配置:untrusted_app.te
platform系统应用配置:platform_app.te

  • 动作集

dir:
create_dir_perms、search、r_dir_perms、rw_dir_perms、ra_dir_perms
file:
create_file_perms、r_file_perms、rx_file_perms、x_file_perms、rw_file_perms

这里的rw_file_perms是一个包含所有的读写权限
define(r_file_perms’,{ getattr open read ioctl lock }‘)
define(w_file_perms’,{ open append write }‘)
define(rw_file_perms’,{ r_file_perms w_file_perms }')

相关参考

Android SELinux avc dennied权限问题解决方法
一文彻底明白linux中的selinux到底是什么
https://www.cnblogs.com/linhaostudy/p/8662534.html
https://blog.youkuaiyun.com/weixin_43835637/article/details/86508214
https://www.jb51.net/article/128214.htm
https://www.jianshu.com/p/88a92d101532
https://www.freesion.com/article/3645654781
https://www.pianshen.com/article/85991051081
https://www.jianshu.com/p/8b0e72776118
https://blog.youkuaiyun.com/gbmaotai/article/details/82415614

<think>好的,我现在需要帮助用户解决在Android 13中替换SELinux配置后不生效的问题。根据用户提供的引用内容和之前的对话历史,我需要综合这些信息来找到解决方案。 首先,用户提到参考了三个引用,其中引用[2]涉及到修改init/selinux.cpp中的代码,强制将SELinux设置为permissive模式。这可能是一个关键点。用户之前的问题是关于Android 13替换SELinux配置后不生效,所以需要检查修改后的配置是否正确应用。 接下来,我需要考虑SELinuxAndroid中的工作流程。通常在Android启动过程中,SELinux的策略文件会被编译成二进制形式,并加载到内核中。如果用户替换了策略文件,但没有重新编译或者正确加载,配置就不会生效。这可能涉及到是否覆盖了正确的策略文件,比如sepolicy文件的位置是否正确,是否在boot镜像中正确打包。 另外,引用[3]中提到了使用audit2allow工具处理AVC拒绝日志,生成新的策略模块。这可能意味着用户可能需要检查是否有新的AVC拒绝,导致策略未生效,或者自定义策略模块没有正确安装。 然后,用户之前的问题和回答中提到了Java的空指针异常处理,虽然这与SELinux无关,但可能用户是在开发Android应用时遇到系统级配置问题,可能需要同时处理应用层和系统层的错误。 可能的解决步骤包括:确认策略文件是否正确替换并编译,检查启动参数是否禁用SELinux,确保没有其他覆盖配置,检查启动日志是否有错误,处理AVC拒绝,以及验证boot镜像是否正确打包。另外,可能需要考虑Android 13的新特性或变更,例如分区结构或安全增强措施,导致旧方法失效。 需要提醒用户注意,修改SELinux配置可能需要解锁bootloader、刷入修改后的镜像,并且可能影响设备安全性。同时,使用permissive模式可能仅在调试阶段有用,正式版本应保持enforcing模式。 最后,生成相关问题,帮助用户深入理解SELinux配置和调试方法,比如如何编译策略文件、处理AVC日志、使用调试工具等。</think>根据您提供的上下文和Android SELinux配置特性,以下是解决Android 13中SELinux配置替换不生效的完整方案: ### 核心问题定位 1. **策略文件加载优先级问题** Android启动时按顺序加载: ``` /vendor/etc/selinux/precompiled_sepolicy → /vendor/etc/selinux → /system/etc/selinux ``` 如果存在多个策略文件,高优先级路径的配置会覆盖低优先级的[^2] 2. **签名验证机制** Android 13加强了对`sepolicy`文件的签名验证,未正确签名的策略文件会被拒绝加载 --- ### 解决方案步骤 #### 1. 内核参数强制生效(临时调试) 修改设备启动参数: ```shell adb reboot bootloader fastboot oem selinux permissive # 部分设备需要解锁BL ``` 或在内核cmdline添加: ```properties androidboot.selinux=permissive enforcing=0 ``` #### 2. 策略文件替换规范 正确替换路径应为(以Pixel 6为例): ```bash # 解包boot.img后替换策略文件 unpack_bootimg --boot_img boot.img --out boot_unpacked cp custom_sepolicy boot_unpacked/vendor/etc/selinux/precompiled_sepolicy ``` #### 3. 策略编译验证 必须使用AOSP匹配的编译工具链: ```makefile # 在AOSP环境中执行 make -j8 selinux_policy adb push out/target/product/{device}/vendor/etc/selinux/precompiled_sepolicy /vendor/etc/selinux/ ``` #### 4. 签名验证绕过(仅调试) 在`BoardConfig.mk`中添加: ```makefile BOARD_AVB_ENABLE := false ``` #### 5. 动态调试方法 捕获实时拒绝日志: ```shell adb shell "cat /sys/fs/selinux/avc > /sdcard/avc_log.txt" audit2allow -i avc_log.txt -p sepolicy.cil ``` --- ### 关键检查点 1. **启动日志验证** ```shell adb logcat | grep -iE "selinux|sepolicy" # 应出现"Loaded sepolicy file: /vendor/etc/selinux/precompiled_sepolicy" ``` 2. **运行时状态确认** ```shell adb shell getenforce # 应返回Permissive adb shell ls -Z /system/bin # 检查上下文标签 ``` 3. **文件权限验证** 确保替换后的策略文件权限为: ```properties -rw-r--r-- 1 root root [文件大小] sepolicy ``` --- ### 高级调试技巧 1. **AVC拒绝分析工具链** ```mermaid graph LR A[avc_log.txt] --> B(audit2allow) B --> C(.te文件) C --> D{编译} D -->|成功| E[sepolicy.cil] D -->|失败| F[修正策略语法] ``` 2. **SELinux策略覆盖标记** 在`system/sepolicy/private/file_contexts`添加: ```policy # 强制覆盖文件上下文 /system/bin/my_daemon u:object_r:my_custom_exec:s0 ``` --- ### 常见失败原因 1. **策略版本不匹配** Android 13要求策略格式版本>=33,需检查: ```shell adb shell seinfo -v ``` 2. **双重签名冲突** 同时存在VBMeta签名和AVB签名时会产生冲突,需统一签名方案 3. **Odm分区覆盖** 部分厂商设备会从`/odm/etc/selinux`加载策略文件 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值