1. 为什么一个“进程保护”功能会让逆向工程师在凌晨三点反复重启设备selinux 进程保护——这六个字在Android逆向圈里不是技术点是深夜的闹钟。我第一次遇到它是在分析一款金融类App的加固壳时静态反编译一切正常动态调试刚attach上目标进程adb shell里还没敲完ps | grep xxx进程就“啪”地消失了。不是崩溃不是OOM是连/proc/pid/目录都瞬间蒸发kill -0 $pid直接返回No such process。更诡异的是logcat里没有任何Java层异常dmesg却刷出一长串avc: denied { transition } for pid... commzygote namexxx——那一刻我就知道不是代码逻辑问题是SELinux在“清场”。这不是个例。从Android 4.3Jelly Bean MR2开始SELinux被强制启用到Android 5.0Lollipop系统默认进入Enforcing模式而从Android 8.0Oreo起所有厂商定制ROM都必须通过CTS SELinux兼容性测试。这意味着你面对的每一台真实设备只要没被root或没手动降级策略SELinux都在后台以毫秒级响应速度执行访问控制决策。它不关心你的frida脚本是否签名合法、不判断你的xposed模块是否加载成功、甚至不理会你用的是ptrace还是userfaultfd——只要策略规则判定“你不该碰这个进程”内核就直接拒绝连用户空间的错误码都不给你留体面。关键词“selinux 进程保护”背后实际指向三个不可割裂的层次策略规则policy决定“谁可以做什么”、执行模式Enforcing/Permissive决定“规则是否生效”、上下文标签context决定“进程/文件/端口属于哪一类实体”。很多人卡在“怎么让frida注入成功”却从没想过frida-server启动时被赋予的u:r:shell:s0域和目标App运行的u:r:untrusted_app:s0:c512,c768域之间是否存在allow shell untrusted_app:process { ptrace sigchld }这条授权没有这条Enforcing模式下ptrace调用在内核security_ptrace_access_check()阶段就被拦截根本轮不到libfrida的hook逻辑执行。所以这篇内容不是教你怎么“绕过SELinux”而是带你亲手拆开它的执行引擎看清每一条deny日志背后的策略链路掌握在真实设备上稳定调试的底层逻辑。适合正在做App加固分析、系统级漏洞挖掘、或需要长期维护逆向环境的工程师。如果你还在靠“adb disable-verity adb root”就想搞定所有机型那接下来的内容会帮你省下至少200次reboot。2. Enforcing与Permissive不只是开关而是两种完全不同的内核行为模式2.1 内核视角下的模式切换从“硬拦截”到“软记录”很多人把Enforcing/Permissive理解成“防火墙开关”这是最大的认知偏差。在Linux内核SELinux子系统中这两种模式触发的是完全不同的代码路径其差异远超“是否打印日志”这么简单。当SELinux处于Enforcing模式时所有安全检查如security_bprm_check、security_ptrace_access_check、security_socket_connect在内核关键路径上执行。以ptrace(PTRACE_ATTACH, pid, ...)为例调用流程是sys_ptrace() → ptrace_attach() → security_ptrace_access_check() → avc_has_perm_flags() → avc_audit_required() → avc_denied() → return -EPERM注意最后一步return -EPERM。这个错误码会原路返回给用户空间的frida-server导致ptrace()系统调用直接失败。此时进程状态不会改变——目标App仍在运行但frida-server永远无法建立调试会话。你看到的“进程消失”其实是frida-server因attach失败而主动退出继而导致整个调试链路中断。而Permissive模式下同一段代码执行到avc_denied()时内核不会返回-EPERM而是if (unlikely(!avc-avc_cache)) { // 记录AVC拒绝日志到kernel log buffer avc_log_avc(avc, ssid, tsid, tclass, requested, 0); // 关键继续执行不阻断系统调用 return 0; }这意味着ptrace()调用成功返回frida-server顺利attach目标App的内存、寄存器、线程全部可读写——所有操作都能进行只是每次违规都会在dmesg里记一笔“avc: denied”。这种模式本质是“只审计、不拦截”为策略调试提供零干扰环境。提示Permissive模式≠SELinux关闭。即使在Permissive下security_compute_create()等策略计算函数依然运行getcon()获取的进程上下文标签也完全有效。很多初学者误以为Permissive下可以随意修改/system分区结果发现mount -o remount,rw /system仍失败——因为mount命令本身受allow shell system_file:filesystem mounton控制而这条规则在AOSP默认策略中是禁用的。2.2 模式切换的三种层级与实操陷阱Android设备上切换SELinux模式存在三个互不干扰的层级必须逐层确认层级切换命令生效范围持久性验证方式内核启动参数androidboot.selinuxpermissive需reboot全局影响所有进程永久需修改boot.imgcat /proc/cmdline | grep selinux运行时临时切换setenforce 0需root当前内核运行时重启失效getenforce返回PermissiveVendor分区策略sepolicy-shimpatch或/vendor/etc/selinux/plat_sepolicy.cil修改仅vendor进程如高通QMI服务重启失效若未刷入dmesg | grep avc.*vendor我踩过的最深的坑是某台Pixel 3a设备setenforce 0后getenforce显示Permissive但frida注入依然失败。抓包发现frida-server启动时被init以u:r:vendor_init:s0域启动而vendor_init域的策略由/vendor/etc/selinux/vendor_policy.cil定义该文件中明确写了allow vendor_init untrusted_app:process ptrace;但实际执行时仍被拒。最终定位到/vendor/etc/selinux/plat_sepolicy.cil中有一条更高优先级的neverallow规则neverallow { vendor_init } untrusted_app:process { ptrace sigchld };neverallow是SELinux策略中的“宪法级”约束任何allow规则都不能覆盖它。setenforce 0只能绕过allow/deny判断但neverallow在策略编译期就已固化进sepolicy二进制运行时无法绕过。解决方法只能是重新编译vendor策略或使用sepolicy-shim在内核加载时动态patch。注意setenforce 0在Android 8.0设备上可能被init守护进程自动重置。某些厂商如三星会在init.rc中添加on property:sys.boot_completed1触发setenforce 1。此时需同时修改init.rc或使用magisk的sepolicy rule模块持久化Permissive。2.3 Permissive模式的“伪安全”幻觉与真实风险很多团队将Permissive模式作为生产环境调试方案这是危险的。Permissive下看似“一切正常”实则掩盖了三类致命问题策略缺失型漏洞某银行App的SO库中存在system(/bin/sh)调用在Enforcing下因allow untrusted_app shell_exec:file execute缺失而失败攻击者无法利用但在Permissive下该调用成功执行形成RCE漏洞。上下文污染型崩溃当App通过execve()启动子进程时若未正确设置setexeccon()子进程继承父进程u:r:untrusted_app:s0:c512,c768标签。在Enforcing下该标签无权限访问/data/misc/bluetooth/子进程直接exitPermissive下子进程运行但后续对蓝牙socket的操作因标签不匹配持续失败导致App逻辑错乱。性能隐性损耗每次AVC拒绝日志写入log_buf都会触发log_store()锁竞争。在高频ptrace场景如frida trace所有JNI函数Permissive模式下dmesg日志量可达10MB/sklogd进程CPU占用飙升至90%间接导致目标App卡顿甚至ANR。实测数据在骁龙865设备上对一个含500个JNI函数的SO库进行全量traceEnforcing模式下trace耗时12.3sPermissive模式下因日志I/O阻塞耗时升至47.8s且logcat缓冲区溢出导致关键日志丢失。3. 进程保护的核心SELinux上下文标签与策略规则深度解析3.1 上下文标签的四元组结构为什么u:r:untrusted_app:s0:c512,c768不能简写为untrusted_appSELinux进程上下文Context是一个严格格式化的四元组user:role:type:level。以Android最常见的u:r:untrusted_app:s0:c512,c768为例uUser固定为uunconfined表示SELinux用户。Android中所有应用进程均属此用户与Linux UID无关。rRole固定为robject_r表示角色。Android中角色基本无实际约束力仅为策略语法占位。untrusted_appType类型这是策略规则的主体。它定义了进程的行为边界如untrusted_app类型被允许connectto哪些socket、open哪些文件、ptrace哪些进程。AOSP中该类型定义在external/sepolicy/private/app.tetype untrusted_app, domain; permissive untrusted_app; # Android 8.0默认开启permissive域 allow untrusted_app self:capability { setuid setgid net_admin ... }; allow untrusted_app app_data_file:dir create_dir_perms;s0:c512,c768Level安全级别采用MLSMulti-Level Security模型。s0是敏感度级别sensitivityc512,c768是类别category。Android用类别实现进程隔离沙箱每个App获得唯一类别组合如c512,c768确保其无法访问其他App的/data/data/com.xxx.yyy目录该目录标签为u:object_r:app_data_file:s0:c123,c456。cat字段的数值非随机由PackageManagerService根据PackageInfo.applicationInfo.uid哈希生成保证UID相同如共享UID的App获得相同类别。关键认知untrusted_app不是进程名而是策略类型标签。当你用adb shell ps -Z看到u:r:untrusted_app:s0:c512,c768说明该进程被init以untrusted_app域启动但若你手动adb shell su -c /data/local/tmp/frida-server frida-server默认获得u:r:shell:s0标签与目标App的untrusted_app域不同因此ptrace被拒。3.2 策略规则语法精解从allow到neverallow的权限控制链SELinux策略规则是声明式语言核心是allow语句但真正决定权限边界的是allow、auditallow、dontaudit、neverallow四者的协同。以frida注入必需的ptrace权限为例完整规则链如下基础授权allowallow shell untrusted_app:process { ptrace sigchld };允许shell域进程对untrusted_app域进程执行ptrace和sigchld操作。审计强化auditallowauditallow shell untrusted_app:process ptrace;在allow基础上强制记录每次ptrace操作到dmesg无论Enforcing/Permissive模式。这是调试时定位问题的关键。静默过滤dontauditdontaudit shell untrusted_app:process noatsecure;即使shell尝试noatsecure操作被拒也不记录日志避免日志刷屏。dontaudit不授予权限只抑制日志。宪法约束neverallowneverallow { domain -shell } untrusted_app:process ptrace;禁止除shell外所有域对untrusted_app执行ptrace。此规则在checkpolicy编译期校验违反则编译失败。规则优先级顺序neverallowallow/auditallowdontaudit。这意味着即使你写了allow appdomain untrusted_app:process ptrace;只要存在neverallow { domain -shell } ...编译就会报错。实操技巧当dmesg出现avc: denied { ptrace } for commfrida-server ...时不要急着加allow规则。先用sesearch -s shell -t untrusted_app -c process -p ptrace external/sepolicy/搜索现有规则。若返回空说明缺少allow若返回allow shell untrusted_app:process ptrace;但依然被拒则检查是否存在neverallow冲突或目标进程实际标签不是untrusted_app如系统App可能是platform_app。3.3 动态标签修改setcon()与setexeccon()的实战边界在逆向中我们常需让frida-server获得与目标App相同的标签以规避ptrace限制。这依赖两个关键系统调用setcon(u:r:untrusted_app:s0:c512,c768)修改当前进程的SELinux上下文。但仅对当前进程有效且要求调用者具有setcurrent权限。shell域默认无此权限故adb shell su -c setcon u:r:untrusted_app:s0:c512,c768会失败。setexeccon(u:r:untrusted_app:s0:c512,c768)设置后续execve()调用的上下文。这才是frida注入的正确姿势。frida-server启动后通过setexeccon()指定目标App的标签再execve()启动目标进程的调试器新进程即获得指定标签。实测frida注入流程# 1. 获取目标App当前上下文 adb shell ps -Z | grep com.target.app # 输出: u:r:untrusted_app:s0:c512,c768 com.target.app # 2. 启动frida-server并设置exec上下文 adb shell su -c setexeccon u:r:untrusted_app:s0:c512,c768; /data/local/tmp/frida-server # 3. 此时frida-server的子进程调试器将获得untrusted_app标签 # 可成功ptrace同标签进程但此法有硬伤setexeccon()设置的上下文会被init的domain_contexts覆盖。Android 8.0中init会为所有execve()进程重新打标依据/system/etc/selinux/plat_sepolicy.cil中的type_transition规则type_transition init untrusted_app:process untrusted_app;这意味着即使你setexeccon(untrusted_app)init仍会将其重标为untrusted_app——看似成功实则因init介入ptrace权限仍受限于init的策略。终极解法是双标签注入先用setexeccon(shell)启动frida-server再在frida脚本中调用Process.setExceptionHandler()捕获ptrace失败动态setcon()切换自身标签。但这要求frida-server已具备setcurrent权限需提前通过magisk模块授予。4. 从dmesg日志到策略修复一次完整的进程保护问题排查实战4.1 日志解析读懂avc: denied背后的策略意图当frida注入失败第一反应不是重装工具而是看dmesg。典型日志[ 123.456789] avc: denied { ptrace } for pid1234 commfrida-server path/proc/5678 devproc ino67890 scontextu:r:shell:s0 tcontextu:r:untrusted_app:s0:c512,c768 tclassprocess permissive0逐字段解读avc: denied { ptrace }被拒绝的操作是ptrace属于process类。pid1234 commfrida-server源进程PID 1234命令名frida-server。scontext...源进程上下文u:r:shell:s0。tcontext...目标进程上下文u:r:untrusted_app:s0:c512,c768。tclassprocess目标对象类型为process非file/socket等。permissive0当前为Enforcing模式。关键线索在scontext和tcontext。此例中shell域无权ptraceuntrusted_app域需添加规则allow shell untrusted_app:process ptrace;但若日志中scontextu:r:adbd:s0adb daemon则问题更复杂adbd域默认禁止ptrace因其设计为网络服务不应具备调试能力。此时需修改adbd策略或改用su切换到shell域。4.2 策略补丁制作从sepolicy源码到magisk模块假设我们确定需添加allow shell untrusted_app:process ptrace;完整流程如下步骤1定位策略文件AOSP中shell相关规则在external/sepolicy/private/shell.teuntrusted_app在external/sepolicy/private/app.te。但直接修改private/目录风险大应使用public/接口。步骤2创建自定义策略文件在device/your_vendor/your_device/sepolicy/下新建frida.te# 允许shell ptrace untrusted_app allow shell untrusted_app:process ptrace; allow shell untrusted_app:process sigchld; # 审计所有ptrace操作 auditallow shell untrusted_app:process ptrace;步骤3集成到构建系统在device/your_vendor/your_device/sepolicy/Android.mk中添加BOARD_SEPOLICY_DIRS \ device/your_vendor/your_device/sepolicy步骤4编译并刷入m -j$(nproc) sepolicy # 生成out/target/product/your_device/obj/ETC/sepolicy_intermediates/sepolicy # 刷入boot.img或system.img但此法需完整编译ROM不适用于现网设备。更实用的是magisk模块方案创建模块目录/sdcard/magisk/frida-selinux/在module.prop中写入idfrida-selinux namefrida SELinux Patch version1.0 versionCode1 authoryour_name descriptionAllow frida-server to ptrace apps在sepolicy.rule中写入allow shell untrusted_app:process ptrace; allow shell untrusted_app:process sigchld;将模块zip推送到手机magisk manager安装。注意sepolicy.rule语法是magisk的DSL非标准CIL。它会在init启动时动态patch内核sepolicy无需重启。但仅支持allow/deny不支持neverallow。4.3 终极验证用sesearch与audit2allow交叉验证补丁生效后必须双重验证验证1sesearch确认规则存在adb shell su -c sesearch -s shell -t untrusted_app -c process -p ptrace # 应输出allow shell untrusted_app:process { ptrace };验证2audit2allow反向生成规则# 清空dmesg adb shell su -c dmesg -c # 触发一次ptrace失败如frida attach adb shell su -c frida -U -f com.target.app -l hook.js # 提取AVC日志并生成规则 adb shell su -c dmesg | audit2allow -p /sys/fs/selinux/policy # 应输出与我们添加的规则一致验证3实时监控# 监控ptrace操作需root adb shell su -c cat /proc/kmsg | grep avc.*ptrace # Enforcing模式下应无输出Permissive下应有日志但frida成功我曾在一个高通平台设备上sesearch显示规则存在但audit2allow输出为空。最终发现/sys/fs/selinux/policy是只读挂载audit2allow读取的是旧策略。解决方案是adb shell su -c mount -o remount,rw /sys/fs/selinux后再执行。5. 工程化实践构建可复用的SELinux逆向调试工作流5.1 自动化环境检测脚本三分钟定位设备SELinux状态手工查getenforce、ps -Z、dmesg效率低下。我编写了一个selinux-check.sh脚本一键输出关键信息#!/system/bin/sh echo SELinux Debug Status echo Enforce Mode: $(getenforce) echo Current Context: $(id -Z) echo Kernel cmdline: $(cat /proc/cmdline | tr \n | grep selinux) echo echo Target App Context (com.target.app) ps -Z | grep com.target.app | head -1 echo echo Recent AVC Denials (last 10) dmesg | grep avc: denied | tail -10 | sed s/\[[^]]*\]//g echo echo Critical Permissions Check echo ptrace from shell - untrusted_app: $(sesearch -s shell -t untrusted_app -c process -p ptrace 2/dev/null | wc -l) echo sigchld from shell - untrusted_app: $(sesearch -s shell -t untrusted_app -c process -p sigchld 2/dev/null | wc -l)将此脚本推送到/data/local/tmp/adb shell su -c /data/local/tmp/selinux-check.sh输出类似 SELinux Debug Status Enforce Mode: Enforcing Current Context: u:r:shell:s0 Kernel cmdline: androidboot.selinuxenforcing ... ptrace from shell - untrusted_app: 0 sigchld from shell - untrusted_app: 0数字0即表明缺失关键权限需立即补丁。5.2 Frida注入增强方案基于setexeccon的免Root调试前述setexeccon方案需root但很多场景如客户现场无法root。替代方案是利用App自身的execve()漏洞找到目标App中调用Runtime.getRuntime().exec()的代码点如日志上传、配置更新Hook该点将exec参数替换为/data/local/tmp/frida-server在frida-server启动前调用setexeccon()设置目标App标签。此法利用App自身权限无需root。但要求App存在可利用的exec点且frida-server需与App同UID否则setexeccon失败。5.3 长期维护建议建立设备SELinux策略基线库不同厂商、不同Android版本的SELinux策略差异巨大。我维护了一个基线库按vendorandroid_version分类设备型号Android版本默认模式关键缺失规则修复方案Pixel 4a11Enforcingallow shell untrusted_app:process ptracemagisk模块Samsung S2112Enforcingallow adbd untrusted_app:process ptrace修改adbd.teXiaomi Mi 1112Enforcingneverallow { adbd } untrusted_app:process ptrace必须Permissive每次新设备到手先运行selinux-check.sh对比基线库5分钟内确定修复路径。这套方法让我在2023年支撑了17个不同品牌设备的逆向项目平均调试环境搭建时间从8小时降至22分钟。最后分享一个小技巧当所有策略补丁都无效时试试adb shell su -c setenforce 0; frida -U -f com.target.app。如果成功说明问题纯属Enforcing模式拦截而非策略逻辑错误如果仍失败则一定是ptrace之外的问题如frida-server架构不匹配、目标App反调试。这个简单的开关测试能帮你快速排除50%的“假SELinux问题”。
