Android16 SELinux 关闭方式汇总

Android16 SELinux 关闭方式汇总文章目录Android16 SELinux 关闭方式汇总[toc]一、前言二、SELinux 基础概念1、SELinux 三种状态2、Android 编译版本与 SELinux 的关系3、常用查询命令三、运行时关闭方式临时1、setenforce 命令最常用2、init.rc 脚本方式实际无法修改不推荐3、prop 属性方式AOSP 标准不支持四、编译期/内核级控制方式永久1、源码编译期设置默认 Permissive推荐2、内核级完全关闭bootargs 添加 selinux03、源码修改 system/core/init/selinux.cpp简单粗暴对比四种源码层控制方式的优劣五、源码策略文件修改方式不改开关源码修改 .te 文件编译推荐六、各方式对比汇总七、user 版本限制说明1、user 版本为什么 setenforce 0 不行2、user 版本可行的方案八、调试常用命令速查1、SELinux 状态查询2、AVC 日志排查九、总结一、前言在 Android 系统开发中SELinuxSecurity-Enhanced Linux是强制访问控制MAC的安全模块。开发调试阶段经常遇到 SELinux 权限拦截问题需要临时或永久关闭 SELinux 来排查。一般默认值开启selinux的也就是Enforcing模式有些情况是可以通过命令关闭selinux验证有些情况需要在内核关闭selinux验证因为有些系统服务在启动比较早后期关闭selinux已经不管用了所以需要修改源码或者在内核关闭selinu进行验证如果涉及到selinux权限问题一般修改.te文件就可以解决。本文汇总 Android 系统中关闭 SELinux 的各种方式涵盖运行时临时关闭、内核级永久关闭、策略文件修改等方式并说明 user 版本的限制。二、SELinux 基础概念1、SELinux 三种状态状态说明getenforce返回值is_selinux_enabled()权限检查行为Disabled完全未启用Disabled返回 0完全跳过不做任何检查Permissive宽容模式Permissive返回 1执行检查但只记录日志不阻止Enforcing强制模式Enforcing返回 1执行检查拒绝并记录日志关键区别DisabledvsPermissiveDisabled 时/sys/fs/selinux不挂载selinux_check_access()直接返回 0Permissive 时 SELinux 子系统完整运行只是不阻止。所以你的selinux设置了Permissive 也是打印一大堆权限问题的日志是可以不用管的。PermissivevsEnforcing两者都执行完整的 AVC 策略检查唯一区别是 Permissive 记录但不阻止Enforcing 记录且阻止。2、Android 编译版本与 SELinux 的关系编译版本默认 SELinux 模式adb rootsetenforce 0适用场景engPermissive✅ 可以✅ 可以内部开发调试userdebugEnforcing✅ 可以✅ 可以外部开发调试userEnforcing❌ 不可以❌ 不可以量产版本3、常用查询命令# 查询当前 SELinux 模式getenforce# 输出: Enforcing开启了selinux强制模式 / Permissive关闭selinux宽容模式 / Disabled完全未启用# 查询内核 SELinux 启用状态cat/sys/fs/selinux/enforce# 输出: 1Enforcing, 0Permissive#实际没用什么都没返回# 查看 SELinux 是否完全启用内核级cat/proc/cmdline|grepselinux# 如果有 selinux0 则内核级已关闭#实际没用什么都没返回//查看selinux最开始的状态后续setenforce修改后这个属性也是不会改变的。 console:/# getprop |grep selinux[ro.boot.selinux]:[permissive]上面的命令就getenforce 有点用其他的是没用的。三、运行时关闭方式临时运行时关闭的特点是重启后失效适合临时调试。1、setenforce 命令最常用# 切换到 Permissive 模式宽容模式关闭selinuxsetenforce0# 切换回 Enforcing 模式强制模式开启selinuxsetenforce1# 通过 adb 执行adb shell setenforce0权限要求eng/userdebug版本shell 域有setenforce权限直接可用user版本shell 域没有setenforce权限执行会报Permission denied验证getenforce# 预期输出: Permissive注意setenforce 0只是将模式从 Enforcing 改为 PermissiveSELinux 子系统仍然完整运行。对于某些场景如 wpa_supplicant 访问 keystore2需要重启相关服务才能让进程重新建立连接# setenforce 0 后重启 wpa_supplicantsetenforce0stop wpa_supplicant start wpa_supplicant连接企业网络就遇到过这个问题必须要重启wpa才能生效。2、init.rc 脚本方式实际无法修改不推荐⚠️实际测试结论该方式无效。虽然 init.rc 的语法上支持on boot时调用setenforce 0但实际测试发现无法改变 SELinux 默认模式。无效原因init 启动流程 ① FirstStageInit → 挂载文件系统 ② SelinuxInitialize() → 读取 ro.boot.selinux调用 security_setenforce() ↑ 此处就确定了模式之后不会被 init.rc 重写覆盖 ③ 解析并执行 init.rc 中的 action → 即使 on boot: setenforce 0 ↑ 执行时间太晚或被某些 vendor 的 init 定制流程强制改回 Enforcing ④ boot 阶段完成时机问题SELinux 初始化在SelinuxInitialize()阶段完成发生在 init.rc 解析执行之前或并行。即使 init.rc 的on boot触发setenforce 0执行了也可能被系统后续的恢复流程强制改回 Enforcing。vendor 定制部分厂商在system/core/init/selinux.cpp中强制忽略setenforce的调用或在on property:sys.boot_completed1时强制设置为 Enforcing。编译产物问题如果修改的是 device 源码中的 init.rc需要连同boot.img一起编译否则修改不会真正打包进 boot 分区。如果仍想尝试仅作为记录不保证有效# system/core/rootdir/init.rc 或 device/.../init.rc # 尽量用更早期的触发器但仍可能无效 on post-fs-data setenforce 0 on boot setenforce 0编译时必须连同boot.img或vendor_boot.img一起编译刷入makebootimage vendor_bootimage-j8# fastboot flash boot boot.img3、prop 属性方式AOSP 标准不支持⚠️实际测试结论setprop ro.boot.selinux permissive无效。ro.boot.selinux 的来源链路Bootloader kernel cmdline: androidboot.selinuxpermissive ↓ 内核传入 /proc/cmdline → init 进程 SystemCore Init 解析 androidboot.* ↓ 自动生成只读属性: ro.boot.selinux permissive ↓ system/core/init/selinux.cpp → SelinuxInitialize() 读取该值后设置为 Permissive关键点ro.boot.selinux不是源码中定义的属性也不能通过setprop动态修改ro.只读属性设置无效该属性由 init 进程自动从 kernel cmdline 的androidboot.xxx参数生成有且只有一处来源bootloader/内核启动参数源码中修改该属性没有任何意义因为编译时不会预置这个属性正确做法如果想通过属性控制# device/vendor/device/BoardConfig.mk # 在 bootargs 中添加 androidboot.selinuxpermissive BOARD_KERNEL_CMDLINE androidboot.selinuxpermissive这会导致 boot.img 的 cmdline 中包含androidboot.selinuxpermissive启动后自动生成ro.boot.selinuxpermissive进而被SelinuxInitialize()读取并进入 Permissive 模式。或者直接修改内核 defconfig / bootloader 环境变量添加androidboot.selinuxpermissive到 cmdline。如果源码中没有system/core/init/selinux.cpp项目裁剪了 system/core也可以直接修改 init 的main.cpp在SelinuxInitialize()调用前或调用后强制执行security_setenforce(0)。这里修改 BoardConfig.mk 属性编译源码了并不是简单的prop属性修改。四、编译期/内核级控制方式永久包含两类方式源码编译期控制通过 BOARD_KERNEL_CMDLINE— 影响默认的 SELinux 模式Permissive / Enforcing不关闭内核子系统内核级关闭selinux0 / CONFIG 关闭— 完全关闭 SELinux 子系统1、源码编译期设置默认 Permissive推荐在设备的BoardConfig.mk中通过BOARD_KERNEL_CMDLINE添加androidboot.selinuxpermissive。这是目前在源码层修改 SELinux 默认值最可靠的方式编译进 boot.img 后每次开机自动生效。生效链路BoardConfig.mk 配置 BOARD_KERNEL_CMDLINE androidboot.selinuxpermissive ↓ 编译进 boot.img 的 cmdline /proc/cmdline 含 androidboot.selinuxpermissive ↓ init 进程启动解析 androidboot.* 自动生成属性 ro.boot.selinux permissive ↓ system/core/init/selinux.cpp: SelinuxInitialize() if (property_get(ro.boot.selinux) permissive) { security_setenforce(0); // 设置为 Permissive } ↓ 开机后 getenforce 返回 Permissive ✅修改方式# device/vendor/device/BoardConfig.mk # 在现有的 BOARD_KERNEL_CMDLINE 后追加 BOARD_KERNEL_CMDLINE androidboot.selinuxpermissive如果 device 目录中有多个 BoardConfig如 common、variant需要在实际编译时生效的那个文件里添加。比如AML方案的目录是release/device/amlogic/t7_an400/BoardConfig.mk编译sourcebuild/envsetup.sh lunchyour_targetmakebootimage-j8# 必须编 boot.img因为 cmdline 在 boot.img 里# fastboot flash boot boot.img//如果不想单独替换镜像整编也是有效的。验证getenforce# 预期输出: Permissive2、内核级完全关闭bootargs 添加 selinux0这个不需要重新编译源码但是需要有串口设备设置内核。在内核参数中添加selinux0内核启动时检测到该参数后不初始化 SELinux 子系统。注意selinux0是内核级完全关闭androidboot.selinuxpermissive是用户空间设置为 Permissive两者效果不同前者更彻底。直接修改 bootloader 环境变量U-Boot# 进入 U-Boot 命令行后# 关闭selinuxsetenv EnableSelinux permissive;saveenv;reset#开启selinuxsetenv EnableSelinux enforcing;saveenv;reset验证getenforce# 预期输出: Permissive 或 Enforcing注意此方式与编译版本无关user 版本也可用需解锁 bootloader。3、源码修改 system/core/init/selinux.cpp简单粗暴直接修改 Android init 的 SELinux 初始化逻辑这是最可靠、最直接的源码级修改方式。基于 init 实际代码如下// system/core/init/selinux.cpp 核心逻辑EnforcingStatusStatusFromProperty(){std::string value;// 门 1从 kernel cmdline 读取 androidboot.selinuxpermissiveif(android::fs_mgr::GetKernelCmdline(androidboot.selinux,value)valuepermissive){returnSELINUX_PERMISSIVE;}// 门 2从 bootconfig 读取 androidboot.selinuxpermissiveif(android::fs_mgr::GetBootconfig(androidboot.selinux,value)valuepermissive){returnSELINUX_PERMISSIVE;}returnSELINUX_ENFORCING;// 默认值}boolIsEnforcing(){// 总开关ALLOW_PERMISSIVE_SELINUX 编译常量// true → 允许通过 cmdline/bootconfig 切换为 Permissive// false → 永远返回 Enforcing上层怎么改都没用if(ALLOW_PERMISSIVE_SELINUX){returnStatusFromProperty()SELINUX_ENFORCING;}returntrue;}两道门槛说明门槛控制者作用ALLOW_PERMISSIVE_SELINUX编译时常量在 BuildConfig.generated.h 或类似文件中总开关。如果为 falseStatusFromProperty() 无论返回什么都被忽略永远返回 true (Enforcing)StatusFromProperty()kernel cmdline / bootconfig 的androidboot.selinux具体值。只有总开关为 true 时才会被读取修改方式任选其一不需要同时修改。方式 A直接改IsEnforcing()返回 false最推荐一行搞定// system/core/init/selinux.cppboolIsEnforcing(){// 原代码// if (ALLOW_PERMISSIVE_SELINUX) {// return StatusFromProperty() SELINUX_ENFORCING;// }// return true;// 修改为永远返回 false强制 Permissive 模式// 优点// 1. 绕过 ALLOW_PERMISSIVE_SELINUX 总开关限制// 2. 不需要改 kernel cmdline// 3. 不需要改 bootconfig// 4. 代码最简单可预测性最高returnfalse;}修改上面这个需要把 StatusFromProperty() 函数注释了因为系统编译检测无用会报错要么就是在返回前加上 (void)StatusFromProperty(); // 欺骗编译器标记函数被引用消除unused报错方式 B改StatusFromProperty()永远返回 PERMISSIVE// system/core/init/selinux.cppEnforcingStatusStatusFromProperty(){// 原代码读 cmdline 和 bootconfig// 修改为直接返回 PERMISSIVE不读任何配置returnSELINUX_PERMISSIVE;}// 注意前提是 ALLOW_PERMISSIVE_SELINUX true否则仍然无效// 如果 ALLOW_PERMISSIVE_SELINUX 是 false还是走方式 A 最稳编译sourcebuild/envsetup.sh lunchyour_target# init 属于 boot 分区的可执行文件需要连同 boot.img 一起编译makeinit-j8# 先单独编译 init确认无错误makebootimage-j8# 生成 boot.img# 刷入# fastboot flash boot boot.img验证getenforce# 预期输出: Permissive127|console:/# getprop | grep selinux //虽然prop属性值是enforcing这个不用管[ro.boot.selinux]:[enforcing]# 注意即使 /proc/cmdline 中没有 androidboot.selinuxpermissive也应该是 Permissive# 因为改的是代码逻辑不依赖 cmdline对比四种源码层控制方式的优劣修改方式修改文件代码行数绕过总开关不依赖 cmdline适用场景直接改 IsEnforcing()system/core/init/selinux.cpp1 行✅ 是✅ 是最推荐简单、无前置条件改 StatusFromProperty()system/core/init/selinux.cpp1 行❌ 否受 ALLOW_ 限制✅ 是简单但受总开关限制BoardConfig cmdlinedevice/.../BoardConfig.mk1 行 mk❌ 否受 ALLOW_ 限制❌ 否依赖 cmdline不改 init 源码时用一句话建议能改 system/core/init/selinux.cpp → 直接改IsEnforcing()→ 最稳不能改 system/core项目裁剪了→ 改 BoardConfigBOARD_KERNEL_CMDLINE androidboot.selinuxpermissive想临时切换userdebug 场景→setenforce 0生产环境解决特定权限问题 → 改.te策略不关闭 SELinux五、源码策略文件修改方式不改开关策略文件修改方式不关闭 SELinux而是修改 SELinux 策略规则让特定域获得所需权限。这是Google 推荐的做法不影响整体安全性。这个主要是根据logcat 日志中查看类似的日志SELinux : avc: denied { grant } for scontextu:r:hal_wifi_supplicant_default:s0 tcontextu:object_r:wifi_key:s0 tclasskeystore2_key permissive0源码修改 .te 文件编译推荐在 Android 源码中修改.te策略文件重新编译后刷入镜像。示例为 wpa_supplicant 添加 keystore2 密钥访问权限# system/sepolicy/vendor/hal_wifi_supplicant_default.te # 追加允许 wpa_supplicant 访问 wifi_key 命名空间的密钥 allow hal_wifi_supplicant_default wifi_key:keystore2_key { get_info use manage_blob grant rebind update delete convert_storage_key_to_ephemeral req_forced_op }; # 追加恢复 setuid/setgid 能力 allow hal_wifi_supplicant_default self:global_capability_class_set { setuid setgid };编译步骤# 1. 清除 sepolicy 编译缓存关键rm-rfout/soong/.intermediates/system/sepolicy/rm-rfout/target/product/*/obj/ETC/*sepolicy*# 2. 设置编译环境sourcebuild/envsetup.sh lunchyour_target# 3. 先单独编译策略确认无报错makesepolicy-j8# 4. 编译完整镜像makebootimage vendorimage-j8验证# 刷入后在 Enforcing 模式下验证getenforce# 预期: Enforcing# 查看是否有 AVC 拒绝dmesg|grepavc|grepwpa_supplicant# 预期: 无输出权限已配置selinux denied 权限报错具体如何分析修改后续再做总结。六、各方式对比汇总方式持久性user 版本可用安全性难度适用场景setenforce 0❌ 重启失效❌ 不可用⚠️ Permissive⭐userdebug 临时调试init.rcsetenforce 0❌实际无效❌ 不可用-⭐不推荐测试无法修改默认模式prop 属性方式❌实际无效❌ 不可用-⭐不推荐ro. 只读需改 cmdlineBoardConfigBOARD_KERNEL_CMDLINE✅ 持久✅ 需编镜像⚠️ Permissive⭐⭐源码层 Permissive 推荐方式bootargsselinux0✅ 持久✅ 需解锁 BL❌ 完全关闭⭐⭐⭐内核级调试内核 CONFIG 关闭✅ 持久✅ 需编内核❌ 完全关闭⭐⭐⭐⭐永久关闭源码改 .te 编译✅ 持久✅ 可用✅ 最小权限⭐⭐⭐量产推荐七、user 版本限制说明1、user 版本为什么 setenforce 0 不行关键在 SELinux 策略中的userdebug_or_eng()宏# system/sepolicy/private/shell.te userdebug_or_eng( # 只有 eng/userdebug 版本才编译这段规则 allow shell self:capability { setenforce }; )eng / userdebugshell域有setenforce权限 →adb shell setenforce 0生效user这段策略在编译时被直接移除→shell域没有setenforce权限执行结果console:/ $ setenforce0setenforce: Permission denied同时 user 版本还有以下限制adb root不可用分区只读无法 remount无法修改 init.rc 或 prop 文件2、user 版本可行的方案方式是否可用前提条件源码改 .te 编译✅ 可用有源码编译环境修改 selinux.cppIsEnforcing()返回 false✅ 可用有源码能编译 boot.img最推荐不受任何开关限制BoardConfigandroidboot.selinuxpermissive✅ 可用有源码编译环境且ALLOW_PERMISSIVE_SELINUX truebootargsselinux0✅ 可用需解锁 bootloader内核 CONFIG 关闭✅ 可用需能编译刷入内核setenforce 0❌ 不可用-init.rc 修改❌实际无效SelinuxInitialize() 早于 init.rc 执行setprop ro.boot.selinux❌ 不可用ro. 只读属性设置无效量产推荐源码改 .te 编译不关闭 SELinux只修改策略规则解决权限问题通过 CTS/VTS 认证不受影响。八、调试常用命令速查1、SELinux 状态查询# 查询当前模式getenforce# 查询进程安全上下文ps-Z# 查询文件安全上下文ls-Z2、AVC 日志排查# 实时监控 AVC 日志adb shellcat/proc/kmsg|grepavc# 通过 logcat 查看adb logcat-bkernel|grepavc# 如果有 dontaudit 隐藏日志临时关闭 dontauditWifi 企业网络连接失败# 需要 SELinux 策略支持 auditallowadb shell setenforce0# 临时切 permissive 让所有拒绝都记录adb shell stop wpa_supplicant adb shell start wpa_supplicant# 再查 dmesg# 用 audit2allow 自动生成策略如果有该工具adb shelldmesg|grepavc|grep-iEwpa|keystore|audit2allow九、总结场景推荐方式说明userdebug 临时调试setenforce 0最快有些情况无作用重启失效源码层设置 Permissive编译期推荐修改 selinux.cppIsEnforcing()返回 false最简单、最可靠不受ALLOW_PERMISSIVE_SELINUX开关和 cmdline 限制源码层不改 init 源码BoardConfigBOARD_KERNEL_CMDLINE androidboot.selinuxpermissive编译进 boot.img每次开机自动 Permissive要求ALLOW_PERMISSIVE_SELINUX true内核级调试bootargsselinux0完全关闭 SELinux 子系统量产版本解决问题源码改 .te 编译不关闭 SELinux最小权限原则通过 CTS/VTSinit.rc 脚本 / setprop ro.boot.selinux不推荐实际测试无效一句话总结临时调试 →setenforce 0编译期默认 Permissive →优先改 selinux.cppIsEnforcing()一行不行再用 BoardConfig cmdline源码中能真正落地生效、且稳定可预测的方式有两种改 selinux.cpp IsEnforcing()最稳或 BOARD_KERNEL_CMDLINE androidboot.selinuxpermissive需确认总开关。如果不想编译源码并且是Debug版本有串口工具可以修改内核配置关闭selinux。init.rc 脚本、setprop ro.boot.selinux 都是临时手段或实际无效的方式量产解决问题 → 改.te策略编译