Android 12系统开发者的SELinux生存手册以RK3588自启动服务为例在移动设备系统开发的深水区Android 12引入的更为严格的SELinux策略常常成为开发者从应用层转向系统层时遇到的第一个“拦路虎”。尤其是当你手握一块功能强大的RK3588开发板试图让一个简单的“Hello World”程序随系统开机自启动时原本在Linux环境下轻车熟路的操作在Android的沙盒世界里却可能寸步难行。权限拒绝avc: denied的日志像雪花一样飘来而你甚至不清楚该从哪里入手去“放行”。这篇文章正是为那些有Linux基础却对Android系统权限迷宫感到困惑的开发者准备的。我们不打算复述那些随处可见的官方文档而是直接切入实战以在RK3588平台上配置一个Native服务的完整流程为线索深入SELinux策略编写的肌理。你会看到从文件上下文file_contexts一个不起眼的空行陷阱到如何高效利用audit2allow工具从海量拒绝日志中快速定位问题每一个环节都藏着让新手栽跟头的细节。我们的目标不是让你死记硬背几条策略规则而是帮你建立起一套应对Android SELinux权限问题的系统性思维框架让你下次再看到“avc denied”时能胸有成竹地知道该去哪里、做什么。1. 理解Android SELinux从“完全禁用”到“精细管控”的思维转变很多刚接触Android系统开发的工程师第一个念头往往是能不能直接把SELinux关掉在RK3588的开发板上你确实可以通过adb shell setenforce 0将SELinux切换到宽容Permissive模式让所有权限检查失效。但这就像为了学会游泳而永远待在浅水区——它解决了眼前的启动问题却让你失去了理解系统安全机制的机会并且这绝不是产品化方案。Android SELinux的核心思想是强制访问控制MAC它超越了传统的Linux自主访问控制DAC即用户、组、权限位为每个进程和对象都打上了安全上下文标签所有访问都必须依据一套明确的策略规则来执行。进程域Domain与文件类型Type是SELinux策略中最关键的两个概念。你可以这样理解进程域比如init、system_server、surfaceflinger它定义了进程的运行上下文。我们为自己的服务创建的demo_domain就是一个自定义域。文件类型比如system_file、vendor_file、exec_type它给文件包括可执行文件、设备节点等打上了安全标签。我们为可执行文件定义的demo_exec就是一种自定义类型。策略规则的本质就是声明哪个域Domain的进程可以对哪个类型Type的对象文件、套接字等执行哪些操作读、写、执行等。Android将策略文件分散在/system/etc/selinux/和/vendor/etc/selinux/等目录其中vendor分区是OEM厂商如Rockchip添加自定义策略的主要位置。在RK3588的Android 12源码环境中我们通常在device/rockchip/common/sepolicy/vendor/目录下进行修改。一个常见的策略文件结构如下vendor/sepolicy/ ├── file_contexts # 定义文件路径的安全上下文标签 ├── property_contexts # 定义系统属性的安全上下文 ├── demo.te # 我们自定义服务的主要策略文件类型强制规则 └── ... (其他.te文件)理解这个基础框架是后续所有实战操作的前提。它意味着你的每一个操作——放置文件、启动服务、访问资源——都需要在SELinux的世界里获得合法的“身份”和“通行证”。2. RK3588 Native服务部署超越简单的文件拷贝假设我们已经用Android NDK编译好了一个名为demo的可执行文件以及一个用于启动它的Shell脚本run.sh。在普通的Linux系统中你可能只需要把它们扔进/usr/local/bin并配置一个systemd服务。但在Android尤其是只读分区盛行的世界里你需要遵循它的规则。2.1 文件放置与权限预设Android 8.0以后为了加强系统分区/system的不可变性新增的应用或服务文件通常被要求放在/vendor分区。在RK3588的SDK中device/rockchip/common/是一个存放设备通用配置的目录我们在这里创建自己的文件结构。首先在device/rockchip/common/下创建目录your/bin/并将demo和run.sh放入。接着需要修改device.mk文件利用PRODUCT_COPY_FILES变量在编译时将文件拷贝到镜像中的正确位置。这里有一个关键点必须预先设置好文件权限。# 在 device/rockchip/common/device.mk 中添加 PRODUCT_COPY_FILES \ device/rockchip/common/your/bin/demo:$(TARGET_COPY_OUT_VENDOR)/app/your/bin/demo \ device/rockchip/common/your/bin/run.sh:$(TARGET_COPY_OUT_VENDOR)/app/your/bin/run.sh但这样拷贝过去的文件其权限是由源码文件的权限决定的有时并不准确。由于vendor分区在运行时是只读的我们不能在启动后用chmod修改。这时就需要fs_config机制。我们创建一个config.fs文件来精确设定镜像中文件的权限、所有者和能力。# device/rockchip/common/config.fs [vendor/app/your/bin/run.sh] mode: 0755 user: AID_SYSTEM group: AID_SYSTEM caps: 0 [vendor/app/your/bin/demo] mode: 0755 user: AID_SYSTEM group: AID_SYSTEM caps: 0注意caps字段用于设置Linux能力如WAKE_ALARM对于大多数普通服务设为0即可。如果需要应在此处明确声明。最后在BoardConfig.mk中告诉构建系统使用这个配置文件TARGET_FS_CONFIG_GEN device/rockchip/common/config.fs2.2 定义Init服务与启动时机Android使用init系统来管理进程。我们需要在init.rc文件中定义我们的服务。RK3588的SDK通常将设备相关的init脚本放在device/rockchip/common/rootdir/init.rockchip.rc。服务的定义遵循固定格式service demo /vendor/app/your/bin/run.sh class main user root group root oneshotservice demo定义了一个名为demo的服务。/vendor/app/your/bin/run.sh服务启动时执行的命令。class main属于main类这类服务会在class_start main时被启动。user/group root以root身份运行注意这需要SELinux策略允许。oneshot服务退出后init不会尝试重启它。这对于只执行一次的任务如启动脚本很合适。但我们的目标是在系统启动完成后再启动这个服务以避免在系统关键阶段造成干扰或竞争。我们可以利用属性触发器来实现on property:sys.boot_completed1 start demo这段代码的意思是当系统属性sys.boot_completed的值变为1时触发执行start demo命令。这是一种更优雅、更安全的自启动方式。3. SELinux策略实战从file_contexts到.te文件的完整链路文件放好了服务也定义了但如果没有正确的SELinux标签init进程甚至无法执行你的脚本。SELinux策略的配置是一个环环相扣的过程。3.1 file_contexts给文件贴上“身份证”file_contexts文件的作用是将文件系统路径模式映射到安全上下文。这步必须在编写.te文件之前完成因为你需要先知道你的文件被标记为什么类型。在device/rockchip/common/sepolicy/vendor/file_contexts末尾添加/vendor/app/your/bin/run.sh u:object_r:demo_exec:s0 /vendor/app/your/bin/demo u:object_r:demo_exec:s0这里我们给两个文件都贴上了demo_exec这个类型标签。u:object_r:和:s0是固定格式中间的部分demo_exec才是自定义的类型名。一个至关重要的“陷阱”file_contexts文件的最后一行必须是空行否则在编译sepolicy时可能会报错“failed to load context file”。这个细节极其隐蔽却足以让编译失败务必检查。3.2 编写.te文件定义行为规则.te(Type Enforcement) 文件是SELinux策略的核心它用声明式的语言定义了“谁可以做什么”。我们在device/rockchip/common/sepolicy/vendor/下创建demo.te。让我们逐段解析一个基础但完整的demo.te文件# 1. 定义类型 type demo_domain, domain; # 定义进程域 type demo_exec, exec_type, vendor_file_type, file_type; # 定义可执行文件类型 # 2. 将demo_exec文件与demo_domain域关联起来 # 这意味着当init执行一个标有demo_exec的文件时进程会转换到demo_domain域运行 type_transition init demo_exec:process demo_domain; init_daemon_domain(demo_domain) # 一个宏封装了域转换所需的一系列基础规则 # 3. 允许init进程执行我们的二进制文件并完成域转换 allow init demo_exec:file { getattr open read execute map }; allow init demo_domain:process transition; # 4. 允许demo_domain进程执行它自己通常指通过execve执行自身或子进程 allow demo_domain demo_exec:file { getattr open read execute map execute_no_trans }; # 5. 允许demo_domain访问一些必要的系统资源根据日志动态添加 # 例如如果日志显示需要访问postinstall目录或系统数据目录 allow demo_domain postinstall_mnt_dir:dir { getattr search }; allow demo_domain system_data_root_file:dir { read getattr search };关键点解析init_daemon_domain(demo_domain)这是一个极其重要的宏。它自动生成了一组规则允许init进程将demo_exec类型的文件作为demo_domain域启动。强烈建议始终使用这个宏来初始化一个守护进程域它比手动编写一堆allow规则更安全、更完整。execute_no_trans这个权限允许进程执行一个文件但不进行域转换。当你的脚本run.sh去执行另一个二进制文件demo且你希望子进程仍在同一个域demo_domain中运行时就需要这个权限。如果希望子进程进入另一个域则需要配置不同的类型和type_transition。3.3 处理依赖服务的权限你的服务在运行时可能会与其他系统服务或上下文交互。例如如果你的run.sh脚本被init-insmod-sh这个域可能负责加载内核模块间接调用或者你需要允许通过adb shell手动测试执行就需要额外授权。# 允许shelladb shell环境手动执行测试 allow shell demo_exec:file { execute read open execute_no_trans map getattr }; # 如果init-insmod-sh需要运行你的脚本 allow init-insmod-sh demo_exec:file { execute_no_trans }; allow init-insmod-sh postinstall_mnt_dir:dir { getattr }; allow init-insmod-sh system_data_root_file:dir { read };这些规则通常不是一开始就能写全的需要根据系统运行时产生的拒绝日志来动态补充。这就是下一节的核心内容。4. 高效排错活用audit2allow与日志分析实战编译烧录后通过adb shell pgrep -f demo查看进程是否运行。如果没有使用adb logcat -b all | grep -E \demo|run.sh\过滤日志。当你看到类似下面的输出时SELinux的挑战才真正开始avc: denied { execute_no_trans } for pid1234 commrun.sh path/vendor/app/your/bin/demo devdm-0 ino5678 scontextu:r:demo_domain:s0 tcontextu:object_r:demo_exec:s0 tclassfile permissive0这条日志告诉我们在demo_domain域中运行的run.sh试图对标签为demo_exec的文件执行execute_no_trans操作但被拒绝了。4.1 手动解读AVC Denied日志一条完整的avc: denied日志包含以下关键信息scontext源上下文即发起操作的进程的安全上下文u:r:demo_domain:s0。tcontext目标上下文即被操作对象的安全上下文u:object_r:demo_exec:s0。tclass目标类别如file,dir,socket等。{ denied_perm }被拒绝的权限如execute_no_trans,read,write,open等。手动编写规则时你需要将日志信息翻译成allow语句allow scontext_domain tcontext_type:tclass { denied_perm };对应上面的日志规则就是allow demo_domain demo_exec:file execute_no_trans;4.2 使用audit2allow进行半自动化生成当拒绝日志很多时手动翻译效率低下且易错。audit2allow工具可以帮你自动生成策略规则建议。操作步骤如下收集日志将设备上的所有AVC拒绝日志保存到文件。adb logcat -b all -d | grep \avc:\ avc_log.txt-b all确保抓取所有缓冲区main, system, crash等的日志-d表示抓取当前日志并退出。生成.te规则在装有policycoreutils的Linux主机上通常是你的编译服务器运行audit2allow -i avc_log.txt -o suggested_rules.te这会分析avc_log.txt并将生成的allow语句输出到suggested_rules.te文件中。审慎整合绝对不要盲目地将suggested_rules.te的内容全部复制到你的策略文件中audit2allow是一个“建议”工具它基于最小权限原则生成允许规则但有时会过于宽泛。你需要合并同类项将针对同一scontext、tcontext、tclass的多个权限合并到一个allow语句中。审查合理性问自己我的服务真的需要这个权限吗例如一个后台服务是否需要write系统属性文件如果不需要就不要添加。使用更精确的宏有时audit2allow会生成基础的allow但可能有现成的、更安全的宏可用。比如对于域转换使用init_daemon_domain比一堆单独的allow更好。一个典型的audit2allow输出可能如下你需要将其整合并审阅# 原始输出可能分散 allow demo_domain system_file:dir search; allow demo_domain system_data_root_file:dir read; allow demo_domain default_prop:file open; # 整合后 allow demo_domain system_file:dir search; allow demo_domain system_data_root_file:dir { read getattr search }; # 谨慎评估是否需要操作default_prop或许这是不必要的访问可以先注释掉观察 # allow demo_domain default_prop:file open;4.3 迭代与验证流程SELinux策略的配置是一个迭代过程编译烧录-运行测试-抓取avc日志。分析日志使用audit2allow辅助将必要的、合理的规则添加到你的.te文件。重新编译sepolicy或整个系统。对于快速迭代可以只编译sepolicy模块并推送到设备source build/envsetup.sh lunch rk3588_s-userdebug # 根据你的目标选择 mma -j8 # 在策略文件所在目录编译模块 adb push ${OUT}/vendor/etc/selinux/vendor_sepolicy.cil /vendor/etc/selinux/ adb push ${OUT}/system/etc/selinux/system_sepolicy.cil /system/etc/selinux/ adb shell setenforce 0; adb shell setenforce 1 # 重新加载策略回到步骤1重复直到没有新的、影响功能的avc拒绝日志出现。重要提示在调试期间可以将设备设置为Permissive模式 (setenforce 0)这样SELinux只记录拒绝而不阻止操作。这可以帮助你收集到完整的权限需求列表。但在策略完善后务必切换回Enforcing模式 (setenforce 1)进行最终测试确保在严格模式下一切正常。5. 进阶策略与最佳实践构建健壮的安全配置掌握了基础配置和排错方法后遵循一些最佳实践能让你的SELinux策略更安全、更易维护。5.1 最小权限原则与宏的使用始终遵循最小权限原则只授予服务完成其功能所必需的最少权限。滥用allow * *:* *;这样的通配符规则会彻底破坏SELinux的安全价值。多使用Android SELinux预定义的宏Macros。宏封装了一组相关的、经过验证的规则比手动编写更安全、更简洁。例如init_daemon_domain(mydomain)如前所述用于初始化守护进程域。unix_socket_connect(mydomain, socket_type, peer)允许连接到某类型的Unix域套接字。binder_use(mydomain)允许使用Binder IPC。hal_attribute_client(mydomain)允许客户端访问HAL服务。在system/sepolicy/public/和system/sepolicy/private/目录下查看.te文件可以找到大量宏的定义和使用示例。5.2 属性、Binder与HAL的权限配置现代Android服务往往需要与系统属性、Binder IPC或硬件抽象层HAL交互这些都需要特殊的SELinux规则。系统属性如果需要读取或写入系统属性需要在property_contexts文件中定义属性的安全上下文然后在.te文件中授予权限。# 在 property_contexts 中定义 my.custom.property u:object_r:my_custom_prop:s0# 在 .te 文件中 allow demo_domain my_custom_prop:property_service set; # 或者使用宏 set_prop(mydomain, my_custom_prop)Binder IPC如果服务提供或调用Binder接口需要定义Binder服务上下文并授予call权限这通常涉及hwservice_manager和binder类。HAL访问访问HAL服务通常需要使用hal_client_domain或hal_server_domain等宏并确保在hwservice_contexts中正确声明。5.3 策略模块化与兼容性当为RK3588这类多产品线的平台开发时策略的模块化很重要。可以考虑将特定服务的策略如demo.te,file_contexts条目放在设备树或产品特定的sepolicy目录下如device/rockchip/rk3588/sepolicy/而不是通用的common目录以提高可维护性。另外要关注Neverallow规则。Android的公共策略system/sepolicy/public/中定义了一些neverallow规则禁止某些危险的权限组合。如果你的自定义策略违反了这些规则编译时会报错。这时你需要重新审视你的设计或者在极少数合理情况下考虑是否需要在平台厂商的私有策略中寻求例外但这需要充分的理由和安全评估。最后记得在每次Android大版本升级时例如从Android 12到13重新测试你的SELinux策略。因为Google可能会引入新的约束、改变安全模型或更新宏的定义原有的策略可能需要调整才能在新版本上正常工作。保持策略的简洁、清晰和文档齐全是长期维护的关键。