Android SELinux权限控制：从核心概念到实战调试

1. 从一次权限拒绝引发的思考为什么需要SELinux如果你在Android开发或者系统定制过程中遇到过类似avc: denied的日志并且尝试了chmod 777甚至setenforce 0这种“终极手段”才让应用跑起来那么你已经在和SELinux打交道了。这通常是我们第一次意识到除了传统的DAC自主访问控制Android系统里还有另一套更严格的规则在管事。传统的Linux权限模型DAC很简单一个文件属于某个用户和组然后通过rwx读、写、执行位来控制访问。如果你是文件的所有者或者root你几乎可以为所欲为。这种模型在个人电脑上或许够用但在移动设备上尤其是像Android这样承载着海量第三方应用、涉及支付、隐私数据的系统里就显得力不从心了。一个被恶意应用获取的root权限足以摧毁整个系统的安全防线。SELinuxSecurity-Enhanced Linux的出现就是为了解决DAC的“非黑即白”问题。它引入了一套MAC强制访问控制机制。在MAC模型下一切访问决策不再仅仅基于“你是谁”用户ID而是基于“你是什么”主体/进程的安全上下文、“你想访问什么”客体/文件的安全上下文以及“你想做什么”操作类型。所有的访问规则都由系统策略预先定义任何进程包括root都不能违反。这相当于给系统每个组件都贴上了精细的标签并规定好了谁可以和谁、以何种方式互动。在Android里SELinux不是可选项而是从Android 4.3开始引入并在Android 5.0及以后版本中全面强制启用的核心安全组件。它被深度集成到Binder IPC、属性服务、文件系统等各个角落。理解SELinux对于进行系统级开发、定制ROM、处理系统权限问题乃至进行安全审计都是一项必备技能。很多人觉得它晦涩难懂其实一旦理解了其核心思想和基本操作它就会从一个“麻烦制造者”变成你最得力的“安全守护者”。2. SELinux核心概念拆解标签、规则与域迁移要驾驭SELinux必须先理解它的三个核心概念安全上下文、策略规则和域迁移。这是所有SELinux问题分析和策略编写的基石。2.1 安全上下文系统中的“身份证”在SELinux的世界里每个进程和每个文件系统对象文件、目录、设备节点等都有一个独一无二的“安全上下文”Security Context。你可以把它想象成贴在每个对象上的“身份证”上面写明了它的身份信息。一个完整的安全上下文通常由四部分组成格式为user:role:type:mls_level。在Android系统中我们最常关注的是type字段它是最核心的标识符。user SELinux用户标识。Android中常见的有u普通用户、system_u等但通常不是我们关注的重点。role 角色标识。用于角色基于访问控制RBAC在Android中常见的是r对象角色和object_r。type 类型标识。这是最关键的部分。进程的type通常称为“域”domain文件的type就是其类型。策略规则主要就是针对type来制定的。例如init进程的域可能是init系统/system/bin目录下可执行文件的类型可能是system_file。mls_level 多级安全等级。用于更严格的多级安全模型在标准Android策略中通常为s0。如何查看安全上下文在Android设备的ADB Shell中需要root权限可以使用以下命令查看进程上下文ps -Z或ps -Z -A。你会看到类似u:r:system_app:s0的列这表示一个进程运行在system_app域。查看文件上下文ls -Z。例如查看/system/bin下的文件ls -Z /system/bin/会显示类似u:object_r:system_file:s0的输出。理解当前对象的安全上下文是分析任何SELinux拒绝日志的第一步。2.2 策略规则定义“谁可以做什么”策略规则是SELinux策略的核心它明确规定了允许或禁止哪些访问。策略文件通常以.te(Type Enforcement) 为后缀。一条最基本的TE规则格式如下allow source_type target_type : class permission;allow 关键字表示允许。对应的还有neverallow绝对禁止auditallow允许并记录审计日志等。source_type 源类型通常是进程的域domain。target_type 目标类型通常是文件、目录、套接字、Binder服务等客体的类型。class 客体类别定义了目标的种类如file文件、dir目录、socket套接字、binderBinder服务、property_service属性服务等。permission 针对该客体类别的具体操作权限。例如对file类可以有read,write,execute,open,getattr等对binder类可以有call,transfer等。一个实例如果我们要允许my_app域的进程读取类型为my_data_file的文件规则就是allow my_app my_data_file : file read;策略文件就是由成千上万条这样的规则组成的。Android系统的策略非常庞大它定义了系统服务、应用、硬件抽象层等所有组件之间复杂的交互权限。2.3 域迁移进程身份的“转换”一个进程在生命周期中其安全上下文域并不是一成不变的。最典型的例子就是init进程启动其他服务。init进程本身运行在init域但它通过exec()执行/system/bin/audioserver这个可执行文件时audioserver进程需要从init域转换到audioserver域。这个过程就是“域迁移”Domain Transition。域迁移不是自动发生的它也需要明确的策略规则来授权。这通常涉及两条规则允许父进程在新文件上执行allow init audioserver_exec : file execute;允许域迁移发生allow init audioserver : process transition;定义迁移后的入口点通常由type_transition规则声明type_transition init audioserver_exec : process audioserver;这条type_transition规则的意思是当init域进程执行类型为audioserver_exec的文件时新产生的进程应进入audioserver域。理解域迁移对于编写启动自定义守护进程或服务的策略至关重要。如果你的服务启动后域不对很可能就无法访问它需要的资源。3. 实战如何分析并解决一个SELinux拒绝问题当SELinux阻止了某个操作时它会在内核日志中留下记录。这是我们排查问题的唯一线索。下面我们以一个真实的、在系统开发中常见的场景为例走一遍完整的排查流程。场景我们有一个自定义的系统守护进程my_daemon它需要读取/data/mydata/config.json配置文件。程序编译后我们将其推送到设备/system/bin/my_daemon并尝试运行发现无法读取配置文件日志中出现了SELinux拒绝信息。3.1 捕获拒绝日志首先我们需要获取详细的拒绝日志。有两种主要方式使用dmesg命令在ADB Shell中执行dmesg | grep avc或dmesg | grep denied。avc是Access Vector Cache的缩写是SELinux的审计日志。使用logcat命令SELinux拒绝日志也会输出到Android的日志系统。执行adb logcat -b events | grep avc或使用adb logcat | grep avc进行更广泛的搜索。假设我们捕获到这样一条日志avc: denied { read } for pid1234 commmy_daemon nameconfig.json devdm-0 ino5678 scontextu:r:my_daemon:s0 tcontextu:object_r:unlabeled:s0 tclassfile permissive0这条日志信息量很大我们逐一拆解avc: denied: 表示发生了一次SELinux拒绝。{ read }: 被拒绝的操作是“读”。pid1234 commmy_daemon: 发起操作的进程ID是1234命令名是my_daemon。scontextu:r:my_daemon:s0:源上下文。进程my_daemon运行在my_daemon域。这是我们进程的标签。tcontextu:object_r:unlabeled:s0:目标上下文。文件config.json的安全上下文类型是unlabeled。unlabeled是一个特殊类型通常表示该文件尚未被任何文件上下文规则标记或者创建它的进程没有权限为其设置正确的标签。tclassfile: 目标客体类别是“文件”。permissive0: SELinux处于强制模式permissive1表示宽容模式只记录不拒绝。注意在实际开发中unlabeled类型非常危险。它意味着该文件不受任何策略规则保护任何有文件访问权限的进程都可能读写它。我们的目标应该是为其赋予一个明确、合适的类型。3.2 问题根因分析与解决策略制定根据日志问题很清晰运行在my_daemon域的进程没有被允许读取类型为unlabeled的文件。但是直接添加allow my_daemon unlabeled:file read;是一个极其糟糕的做法。这相当于给my_daemon开了读取所有未标记文件的绿灯严重违背了最小权限原则。正确的解决思路应该是为配置文件定义一个新的、专属的文件类型。在系统启动或文件创建时确保该文件被正确标记为我们定义的类型。只授予my_daemon域进程对这个特定文件类型的必要权限。3.3 编写与集成策略文件Android的SELinux策略文件主要位于/system/etc/selinux/和/vendor/etc/selinux/目录下。对于系统级修改我们通常操作/system/etc/selinux/下的内容对于厂商定制则操作/vendor/etc/selinux/。假设我们为AOSP项目添加一个自定义守护进程步骤通常如下步骤一定义文件类型在my_daemon.te策略文件中我们首先定义一个新的文件类型。通常可执行文件的类型以_exec结尾数据文件的类型以_file或_data_file结尾。# 定义 my_daemon 可执行文件的类型 type my_daemon_exec, exec_type, file_type, vendor_file_type; # 定义 my_daemon 数据文件的类型 type my_daemon_data_file, file_type, data_file_type, vendor_file_type;exec_type,file_type等是属性attribute可以将我们的新类型归类到已有的权限集合中方便管理。步骤二定义进程域并设置域迁移规则继续在my_daemon.te中定义进程域并说明它如何从init域启动。# 定义 my_daemon 进程域 type my_daemon, domain; # 声明 my_daemon 是从 init 域迁移而来的 typeattribute my_daemon mlstrustedsubject; # 可选视情况添加 init_daemon_domain(my_daemon) # 这是一个宏自动生成一系列允许 init 启动 my_daemon 并完成域迁移的规则init_daemon_domain(my_daemon)是Android SELinux提供的一个非常方便的宏它自动展开为一系列规则包括允许init执行my_daemon_exec、允许域迁移、为my_daemon域设置基本权限等。步骤三为进程域授权现在我们需要授予my_daemon域访问其数据文件的权限。# 允许 my_daemon 域进程对其数据文件进行读写等操作 allow my_daemon my_daemon_data_file:file { create read write open getattr setattr lock append map unlink rename };这里我们授予了一组文件操作权限。在实际项目中应遵循最小权限原则只授予必要的权限。例如如果只需要读就只给read和open。步骤四定义文件上下文我们需要告诉系统哪些路径下的文件应该被标记为my_daemon_data_file类型。这在一个名为file_contexts的文件中定义。 在file_contexts文件中添加一行/data/mydata(/.*)? u:object_r:my_daemon_data_file:s0这行规则使用正则表达式表示/data/mydata/目录及其下的所有内容其安全上下文类型都应为my_daemon_data_file。步骤五编译与集成将my_daemon.te文件放到system/sepolicy/public/或vendor/sepolicy/目录下取决于你的修改范围。将file_contexts的修改整合到对应的file_contexts文件中。在Android源码根目录执行m selinux_policy或m进行全编译。编译系统会将所有.te文件编译成二进制的策略文件sepolicy。刷机或更新系统镜像。步骤六验证与调试更新系统后重新运行你的守护进程。首先检查文件标签是否正确应用ls -Z /data/mydata/config.json。输出应该是u:object_r:my_daemon_data_file:s0而不是unlabeled。如果标签正确但仍有拒绝再次使用dmesg或logcat查看新的拒绝日志根据日志继续补充策略。在复杂情况下可以临时将SELinux切换到宽容模式来验证是否是SELinux问题setenforce 0。切记这只是调试手段验证完成后务必切回强制模式setenforce 1。绝对不能让用户设备运行在宽容模式。4. Android SELinux策略的架构与扩展点Android的SELinux策略并非铁板一块它提供了清晰的层次结构方便OEM厂商和SoC供应商进行扩展而无需修改AOSP的核心策略。理解这个架构对于进行设备定制和解决厂商特有的权限问题至关重要。4.1 策略层次platform、vendor与odm从Android 8.0Oreo开始SELinux策略被明确分层目的是将AOSP通用策略与设备特定的策略解耦。platform策略 位于system/sepolicy/。这是AOSP提供的核心策略定义了Android框架、系统服务、AOSP应用等的基本交互规则。强烈建议不要直接修改这部分除非你在向上游AOSP提交补丁。vendor策略 位于vendor/${VENDOR}/sepolicy/或device/${VENDOR}/${DEVICE}/sepolicy/。这是设备制造商如三星、小米、高通添加策略的地方。用于定义芯片组驱动、厂商自定义的HAL服务、厂商应用等的权限。这是OEM厂商最主要的策略扩展层。odm策略 位于odm/etc/selinux/。这是为ODM原始设计制造商或运营商预留的扩展层用于针对特定型号或区域的进一步定制。系统在启动时会按照platform-vendor-odm的顺序加载并合并这些策略。后加载的策略可以添加新规则但不能覆盖先前层中已定义的neverallow规则这是硬性限制。4.2 关键策略文件与目录在策略目录下你会看到很多文件*.te Type Enforcement文件包含类型定义和allow规则。这是最主要的策略文件。file_contexts 将文件路径模式关联到安全上下文。系统在启动、恢复或执行restorecon命令时会根据这个文件来给文件系统打标签。property_contexts 将属性键ro.xxx,persist.xxx等关联到安全上下文。控制哪些域可以读取或设置哪些属性。service_contexts 将Binder服务名如activity,window关联到安全上下文。控制哪些域可以查找、调用哪些Binder服务。hwservice_contexts 类似于service_contexts但用于HIDL HAL服务。genfs_contexts 为内核虚拟文件系统如proc,sysfs中的文件指定安全上下文。mac_permissions.xml 与应用签名和包名相关用于确定应用进程的初始SELinux域如platform_app,untrusted_app。4.3 厂商扩展的最佳实践与常见坑在为设备添加自定义策略时有几条黄金法则始终在vendor层添加 除非你的修改适用于所有Android设备否则永远在vendor或odm目录下添加你的.te和file_contexts条目。善用属性Attribute 不要直接对domain或file_type授权。先为你新定义的域或文件类型添加合适的属性然后对属性授权。例如如果你的守护进程需要网络访问可以type my_daemon, domain, mlstrustedsubject;然后net_domain(my_daemon)。net_domain是一个宏它内部可能已经包含了allow my_daemon socket:...等一系列规则。警惕neverallow规则 AOSP的platform策略中包含大量的neverallow规则这是安全底线。例如禁止vendor域的进程直接访问system_data_file。如果你的策略触发了neverallow冲突编译会直接失败。这时你需要重新审视你的设计通常的解决方案是为你的数据定义一个新的、专属的文件类型如前文所述。或者通过一个已有的、有权限的中间服务如system_server来代理访问并使用Binder IPC进行通信。正确处理文件标签 最大的坑之一就是文件创建时的标签。如果一个运行在A域的进程创建了一个文件默认情况下这个文件会继承父目录的上下文类型或者进程创建文件时自带的默认类型由策略决定。如果你发现创建的文件类型不对需要检查file_contexts中对应路径的规则是否正确。确保在创建文件后有机制如init.rc脚本中的restorecon命令或进程自身调用selinux_android_restorecon能根据file_contexts重新标记文件。在策略中为创建文件的域添加relabelto权限到目标文件类型allow A my_data_file:file relabelto;。5. 高级调试技巧与工具链当遇到复杂的SELinux问题时仅靠dmesg可能不够。下面介绍一些更强大的工具和方法。5.1 使用audit2allow快速生成策略补丁audit2allow是一个能将SELinux拒绝日志avc日志自动转换为allow规则的工具。它在开发环境中非常有用。基本用法将设备的avc日志保存到文件比如avc_log.txt。在主机有Android源码环境上执行cd /path/to/android/source source build/envsetup.sh lunch your_target audit2allow -i avc_log.txt -p out/target/product/your_device/vendor/etc/selinux/precompiled_sepolicy-i指定输入日志文件-p指定预编译的策略文件用于理解现有的类型定义。这个命令会输出类似下面的建议规则# my_daemon allow my_daemon unlabeled:file read;重要警告audit2allow给出的建议通常是最小化、临时性的解决方案。它只会针对日志中的拒绝生成允许规则而不会考虑安全架构。如前所述直接允许访问unlabeled是危险的。你应该将audit2allow的输出作为线索理解缺少了什么然后去创建合适的类型和规则而不是盲目添加其输出的规则。5.2 宽容模式Permissive Mode与强制模式Enforcing Mode强制模式setenforce 1或getenforce返回Enforcing SELinux策略真正生效违反规则的操作将被内核拒绝。这是生产设备必须处于的状态。宽容模式setenforce 0或getenforce返回Permissive SELinux策略仅记录日志avc: denied但不会实际拒绝操作。这是极其重要的调试工具。使用场景当你的新功能或应用在强制模式下无法工作时首先切换到宽容模式adb shell setenforce 0。重新测试功能同时收集日志adb shell dmesg | grep avc avc_log.txt。分析日志找出所有拒绝项。根据日志补充或修正策略。策略修改并刷机后务必切回强制模式进行最终测试adb shell setenforce 1。确保在强制模式下一切功能正常。你可以在内核命令行或BoardConfig.mk中为特定域设置宽容模式例如androidboot.selinuxpermissive或androidboot.selinuxpermissive my_daemon仅my_daemon域宽容这对于调试单个组件非常有用。5.3 策略分析与可视化工具对于深度的策略审计或架构分析有一些更专业的工具sesearch 用于在已编译的策略二进制文件中搜索特定规则。例如查找所有允许my_daemon域的规则sesearch -A -s my_daemon precompiled_sepolicy。sepolicy-analyze Android源码system/sepolicy/tools/下的工具可以分析策略检查某些属性或验证neverallow规则。APEXAndroid Policy EXplorer等可视化工具 有些第三方工具或研究项目提供了策略的可视化浏览可以更直观地查看类型之间的关系和允许规则但对于日常调试并非必需。5.4 一个复杂的排错案例Binder调用被拒绝假设你的自定义服务my_service通过Binder向客户端提供接口但客户端调用时出现SELinux拒绝。日志可能类似avc: denied { call } for pid client_pid commclient_app scontextu:r:client_app:s0 tcontextu:r:my_service:s0 tclassbinder permissive0这表示client_app域不允许对my_service域的Binder对象进行call操作。解决方案在服务端my_service.te 需要允许my_service将自己添加到Binder上下文管理器并允许客户端调用。通常使用宏binder_use(my_service)和binder_service(my_service)。binder_service宏会生成类似allow client_app my_service:binder call;的规则具体取决于宏定义。检查service_contexts文件 确保你的Binder服务名例如my.interface.name被正确映射到了my_service的安全上下文。需要添加一行my.interface.name u:object_r:my_service:s0。客户端权限 如果客户端也需要特定的Binder客户端权限可能需要在client_app.te中添加binder_call(client_app, my_service)。处理Binder的SELinux策略时务必仔细查阅AOSP中类似服务如servicemanagersurfaceflinger的.te文件模仿它们的模式来编写规则这是最可靠的方法。