KernelSU 深度解析基于内核的 Android root 方案与可定制特权架构【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是一款运行在 Linux 内核态的 Android root 解决方案面向 GKIGeneric Kernel Image设备设计。本文以其官方站点首页website/docs/pt_BR/index.md所归纳的四大核心特性为主线——基于内核的实现、root 访问控制、可定制的 root 特权、Metamodule 元模块系统——结合仓库内核源码与用户态实现逐层拆解其架构设计与实战配置帮助读者理解 KernelSU 与 Magisk 等传统方案的差异并掌握 App Profile、Metamodule 等核心机制的配置方法。一、基于内核root 能力全部在内核态实现KernelSU 的核心设计理念是Kernel-based——正如站点首页所述KernelSU 运行在 Linux 内核中从而对用户态应用拥有更强的控制能力website/docs/pt_BR/index.md。与传统在用户态如通过 init 进程或 daemon实现 root 的方案不同KernelSU 将权限判定、su 实现、SELinux 规则加载等逻辑全部下沉到内核态。官方介绍文档指出这种内核模式提供了一系列以往难以获得的内核接口能力例如在内核态为任意进程添加硬件断点以不可见的方式访问任意进程的物理内存在内核空间拦截任意系统调用syscall。这些能力在仓库源码中均有对应实现系统调用拦截逻辑位于 kernel/hook/arm64/syscall_hook.c 与 kernel/hook/x86_64/syscall_hook.c通过 kernel/hook/syscall_hook_manager.c 统一管理LSMLinux Security Module挂钩与 setuid 挂钩分别位于 kernel/hook/lsm_hook.c 与 kernel/hook/setuid_hook.c。可见KernelSU 的能力边界直接建立在内核机制之上这也是它与用户态 root 方案在检测面、稳定性上产生本质差异的根源。二、Root 访问控制只有被允许的应用才能感知 su首页将Root access control列为第二大特性只有被授权的应用可以访问或看到su其余应用对此一无所知。这意味着 root 权限的授予不是应用主动申请、系统被动放行而是由内核根据白名单主动判定。从源码看这一机制由内核策略模块实现核心文件为 kernel/policy/allowlist.c白名单数据结构内核以 RCU 哈希表allow_list维护所有应用配置文件struct app_profile并在变更时通过ksu_persistent_allow_list()将整个白名单序列化写入/data/adb/ksu/.allowlist文件包含文件魔数0x7f4b5355与格式版本号下次启动时由ksu_load_allow_list()重新加载权限判定入口__ksu_is_allow_uid()是核心判定函数——系统级 UID小于 2000 且非 1000直接拒绝Manager 应用is_uid_manager永远放行其余应用只在白名单中存在且allow_su true时才被允许Manager 身份识别在 kernel/manager/manager_identity.h 中内核通过ksu_manager_appid记录 Manager 应用的 appid以current_uid().val % KSU_PER_USER_RANGE的方式识别KSU_PER_USER_RANGE为 100000对应 Android 多用户 UID 分段is_manager()用于判定当前进程是否为 Manager 进程默认非 root 行为在init_default_profiles()中默认非 root 配置的umount_modules true见 kernel/policy/allowlist.c即默认对未授权应用卸载模块挂载点。从默认非 root 应用完全感知不到 root 与模块改动这一设计可以看出KernelSU 将隐藏与最小暴露作为访问控制的基本盘而不仅是简单的授权开关。三、可定制的 root 特权App Profile / Root Profile首页第三大特性是Customizable root privilegesKernelSU 允许定制 su 的 uid、gid、groups、capabilities 与 SELinux 规则从而加固 root 特权。这套机制在官方文档中被称为App Profilewebsite/docs/pt_BR/guide/app-profile.md。对于被授予 root 权限的应用其对应的配置文件即Root Profile可定制执行su后进程的uid、gid、groups、capabilities与 SELinux 域实现最小权限原则。3.1 内核中的数据结构App Profile 的完整结构定义在 UAPI 头文件 kernel/include/uapi/app_profile.hmanager 侧的镜像位于 manager/app/src/main/cpp/uapi/app_profile.h关键字段如下version配置文件版本号当前为KSU_APP_PROFILE_VER 4key通常是应用包名最长KSU_MAX_PACKAGE_NAME256 字节curr_uid应用当前 UIDallow_su是否允许使用 surp_configroot 配置包含use_default是否使用默认 root 配置、template_name可引用模板、以及root_profile结构nrp_config非 root 配置use_default与umount_modules是否卸载模块挂载。struct root_profile则具体承载可定制项uid/gid__s32类型指定 su 后进程的用户与组groups[KSU_MAX_GROUPS]补充组列表最多支持 32 个组KSU_MAX_GROUPScapabilitieseffective / permitted / inheritable 三组 64 位能力位图selinux_domain[KSU_SELINUX_DOMAIN]SELinux 域字符串最长 64 字节namespaces命名空间策略默认KSU_NS_INHERITEDflags可启用FLAG_KSU_NO_NEW_PRIVS1ULL 0。内核在ksu_set_app_profile()中对配置进行校验版本、key 长度、groups 数量、SELinux 域合法性并通过ksu_get_root_profile()在 su 授权时读取生效配置见 kernel/policy/allowlist.c。3.2 uid / gid / groups把root降级为 shell在 Linux/Android 中UID 0 是 root 用户GID 0 是 root 组Android 每个应用是一个独立用户0为 root、1000为 system、2000为 ADB shell、10000~19999为普通应用区间工作资料通过 UID 区间分段实现如110000~119999。官方文档给出了一个典型示例——在 ADB shell 中执行idoriole:/ $ id uid2000(shell) gid2000(shell) groups2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) contextu:r:shell:s0Root Profile 可以做到某 root 应用的 Root Profile 将 uid 设为2000则它执行su后实际权限只是 ADB shell 级别再移除inet组对应网络访问权限则该 su 进程无法访问网络。需要特别注意的是App Profile只控制 su 进程本身的权限不控制应用自身权限——应用若已申请网络权限即使不给 su 加inet组它自己仍能联网。3.3 Capabilities拆分 root 特权Linux 2.2 起将超级用户的特权拆分为独立的能力单元capabilities。例如CAP_DAC_READ_SEARCH表示绕过文件读取及目录读/执行权限检查的能力若 UID 为 0 的进程缺少该能力即使是 root 也无法随意读取文件。Root Profile 的capabilities三组位图effective / permitted / inheritable正是为此设计某些 root 应用必须保持 UID 0此时通过裁剪 capabilities 限制其操作集合比一刀切的全量 root 更安全。官方强烈建议先阅读 Linux capabilities 手册man capabilities再定制。3.4 SELinux 域MAC 级细粒度控制SELinux 是强制访问控制MAC机制遵循默认拒绝原则。Root Profile 可将 su 进程从默认的无限制域如u:r:ksu:s0切换到自定义域如u:r:app1:s0并为该域编写专用规则type app1 enforce app1 typeattribute app1 mlstrustedsubject allow app1 * * *注意allow app1 * * *仅用于演示实际不应大规模使用否则与 Permissive 模式无异。内核侧的默认域常量定义在 kernel/policy/allowlist.c 中KSU_DEFAULT_SELINUX_DOMAIN u:r: KERNEL_SU_DOMAIN :s0。3.5 提权风险Escalation与 NO_NEW_PRIVSRoot Profile 配置不当可能引发提权逃逸。官方给出的典型案例若已授予 ADB shellUID 2000root 权限同时将一个普通应用的 Root Profile 的 uid 设为 2000则该应用可连续执行两次su获得完整 root第一次su切换到 UID 2000第二次su因 UID 2000 已被授权而获得完整 root。缓解手段是开启FLAG_KSU_NO_NEW_PRIVS对应app_profile.h中的flags位。但该标志只能阻止 KernelSU 再次为该进程提权进程仍可能通过其他 Linux 机制逃逸因此权限设置务必谨慎。3.6 非 root 配置Umount modules对于未获 root 权限的普通应用App Profile 可控制内核与模块系统对它们的表现——典型配置项是umount_modules卸载模块挂载。由于模块通过 OverlayFS 等方式修改/system部分对系统完整性敏感的应用会因此异常可通过卸载模块挂载来规避。Manager 设置中提供默认卸载模块选项默认开启两种策略保持默认开启在需要加载模块的应用的 App Profile 中单独关闭白名单思路关闭默认选项在需要卸载模块的应用中单独开启黑名单思路。从源码看内核通过ksu_uid_should_umount()决策见 kernel/policy/allowlist.cManager 永不卸载有白名单记录且允许 su 的应用不卸载其余按默认配置或应用专属配置决定。官方文档还提示内核 5.10 及以上版本内核会直接执行卸载动作低于 5.10 的设备需自行 backportpath_umountfs/namespace.c才有实际效果。四、Metamodule可插拔的模块基础设施首页第四大特性是Metamodule system可插拔的模块基础设施允许对 /system 进行 systemless 修改安装 meta-overlayfs 之类的 metamodule 即可启用模块挂载。这一机制在 website/docs/pt_BR/guide/metamodule.md 中有完整论述。4.1 什么是 MetamoduleMetamodule 是一种特殊的 KernelSU 模块为普通模块提供基础设施服务普通模块负责修改什么文件metamodule 负责如何安装与挂载metamount.sh、metainstall.sh、metauninstall.sh三个 hook 脚本分别覆盖挂载、安装、清理。核心特征基础设施角色普通模块的运行依赖 metamodule 提供的服务单实例约束同一时刻只能安装一个 metamodule优先执行metamodule 脚本先于普通模块脚本执行三个 hook覆盖安装、挂载与清理三个阶段。设计动机在于传统 root 方案把挂载逻辑内置在核心中既容易被检测、又难以演进。KernelSU 通过关注点分离把挂载实现外包给插件内核自身不做挂载降低检测面、核心 daemon 保持稳定、社区可以独立演进挂载策略overlayfs / magic mount / FUSE / 自定义 VFS 挂载等用户按需选择实现。4.2 用户视角安装、验证与卸载安装 metamodule 与安装普通模块完全一致下载 ZIP如meta-overlayfs.zip→ 打开 KernelSU Manager → 点击悬浮按钮➕→ 选择 ZIP → 重启设备。安装后可在 Manager 的模块列表页看到带特殊标记的 metamodule。卸载时有醒目的危险提示卸载 metamodule 会影响所有模块——重启后模块将不再挂载直到安装新的 metamodule。由于单实例约束切换 metamodule 需按卸载全部普通模块 → 卸载 metamodule → 重启 → 安装新 metamodule → 重装普通模块 → 重启的顺序进行。关键提醒没有安装 metamodule 时模块不会被挂载。因此全新安装 KernelSU 后若需使用带文件改动的模块必须先行安装 metamodule仅使用脚本、sepolicy 或 system.prop 的模块则不需要。4.3 开发者视角如何编写 Metamodule一个 metamodule 由module.prop中的metamodule1或metamoduletrue标识无该属性即视为普通模块。文件结构my_metamodule/ ├── module.prop (必须包含 metamodule1) │ │ *** Metamodule 专属 hook *** ├── metamount.sh (可选自定义挂载处理器) ├── metainstall.sh (可选普通模块安装 hook) ├── metauninstall.sh (可选普通模块清理 hook) │ │ *** 标准模块文件全部可选*** ├── customize.sh (安装定制) ├── post-fs-data.sh (post-fs-data 阶段脚本) ├── service.sh (late_start service 脚本) ├── boot-completed.sh (开机完成脚本) ├── uninstall.sh (metamodule 自身的卸载脚本) ├── system/ (systemless 修改如需) └── [其他附加文件]三个 hook 脚本的职责与时机metamount.sh挂载处理器在post-fs-data阶段、所有模块脚本执行之前运行负责以 systemless 方式挂载所有已启用模块需检查skip_mount/disable标记。⚠️ 关键要求挂载操作的 source/device 必须命名为KSU如mount -t overlay -o lowerdir... KSU /target或 Rust 侧fsconfig_set_string(fs, source, KSU)?内核卸载与 zygisksu 的卸载依赖此标识metainstall.sh安装 hook在模块安装时、文件解压后由内置安装器source执行类似customize.sh继承install.sh的全部变量与函数MODPATH、TMPDIR、ZIPFILE、ARCH、API、IS64BIT、KSU、KSU_VER、KSU_VER_CODE、KSU_UAPI_VER、KSU_RUNTIME_MODE、KSU_LATE_LOAD、BOOTMODE等以及ui_print、abort、set_perm、set_perm_recursive、install_module等函数注意安装 metamodule 自身时不会调用该 hookmetauninstall.sh清理 hook在普通模块被卸载、目录删除之前运行通过MODULE_ID环境变量获知被卸载模块用于清理文件、symlink 与内部追踪。4.4 执行顺序metamodule 的存在改变了系统启动脚本的执行时序官方文档给出了完整顺序post-fs-data 阶段: 1. 公共 post-fs-data.d 脚本 2. 清理模块、restorecon、加载 sepolicy.rule 3. metamodule 的 post-fs-data.sh如存在 4. 普通模块的 post-fs-data.sh 5. 加载 system.prop 6. metamodule 的 metamount.sh └─ 以 systemless 方式挂载所有模块 7. post-mount.d 阶段 - 公共 post-mount.d 脚本 - metamodule 的 post-mount.sh如存在 - 普通模块的 post-mount.sh service 阶段: 1. 公共 service.d 脚本 2. metamodule 的 service.sh如存在 3. 普通模块的 service.sh boot-completed 阶段: 1. 公共 boot-completed.d 脚本 2. metamodule 的 boot-completed.sh如存在 3. 普通模块的 boot-completed.sh要点metamount.sh在所有 post-fs-data 脚本含 metamodule 与普通模块之后执行metamodule 的生命周期脚本始终先于普通模块.d公共脚本先于 metamodule。另外metamodule 安装后内核会创建稳定 symlink/data/adb/metamodule - /data/adb/modules/metamodule_id无论 metamodule 的 id 是什么都能通过固定路径访问当前激活的 metamodule。4.5 参考实现meta-overlayfsmeta-overlayfs是官方参考实现完整指南见 website/docs/pt_BR/guide/metamodule.md采用双目录架构元数据目录/data/adb/modules/存放module.prop、disable、skip_mount标记启动时扫描快、占用小内容目录/data/adb/metamodule/mnt/存放模块真实文件system、vendor、product 等保存在 ext4 镜像modules.img中利用 ext4 特性优化空间。其metamount.sh的核心逻辑是先挂载 ext4 镜像再导出双目录环境变量并执行 Rust 编写的挂载二进制#!/system/bin/sh MODDIR${0%/*} IMG_FILE$MODDIR/modules.img MNT_DIR$MODDIR/mnt # 若尚未挂载则挂载 ext4 镜像 if ! mountpoint -q $MNT_DIR; then mkdir -p $MNT_DIR mount -t ext4 -o loop,rw,noatime $IMG_FILE $MNT_DIR fi # 为双目录支持设置环境变量 export MODULE_METADATA_DIR/data/adb/modules export MODULE_CONTENT_DIR$MNT_DIR # 执行挂载二进制真实挂载逻辑在 Rust 二进制中 $MODDIR/meta-overlayfs其挂载特性包括使用内核 overlayfs 实现真正的 systemless 修改支持 system、vendor、product、system_ext、odm、oem 多分区通过/data/adb/modules/.rw/提供读写层所有 overlay 挂载设置devKSU以便识别。五、安装与运行模式概览KernelSU 自 0.9.0 起支持两种运行模式详见 website/docs/pt_BR/guide/installation.mdLKM 模式Loadable Kernel Module以可加载内核模块方式注入不替换设备原内核。优点是不触发 AVB、可临时卸载、OTA 升级便利、更新时可在 Manager 中直接安装适合日常使用的手机。GKI 模式Generic Kernel Image用 KernelSU 提供的通用内核镜像替换设备原内核。通用性强Samsung KNOX 等设备 LKM 无法工作只能走 GKI、不依赖厂商固件更新适合模拟器、WSA、Waydroid 等场景。安装层面LKM 模式可经由 Manager选择文件 / 直接安装 / 安装到非活动 slot或命令行工具ksud完成核心命令为ksud boot-patch -b boot.img --kmi android13-5.10boot-patch支持-b/--boot、-k/--kernel、-m/--module、-i/--init、-u/--ota、-f/--flash、-o/--out、--magiskboot、--kmi等选项实现在 userspace/ksud/src/boot_patch.rs。GKI 模式则可通过 KernelSU 提供的通用 boot.img、AnyKernel3 ZIP配合 Kernel Flasher 或 TWRP 等、或手工 magiskboot 修补等方式安装。无论何种方式安装前务必确认设备 KMI 与安全补丁级别兼容并备份原始 boot/init_boot 镜像备份存放于/data/adb/ksu/ksu_backup_$SHA1。六、进一步阅读围绕本文涉及的四个核心特性可在仓库中继续深入O que é KernelSU?什么是 KernelSU内核模式能力总览App Profile 指南uid/gid/groups/capabilities/SELinux 完整配置说明Metamodule 指南metamodule 开发与 meta-overlayfs 详解安装指南LKM / GKI 两种模式的完整安装流程与 Magisk 的差异模块格式、BusyBox 路径、.replace与REMOVE/REPLACE变量、boot-completed 与 post-mount 阶段等差异模块指南普通模块开发规范源码级实现白名单与 App Profile 见 kernel/policy/allowlist.c结构定义见 kernel/include/uapi/app_profile.hManager 身份识别见 kernel/manager/manager_identity.hsyscall 挂钩见 kernel/hook/arm64/syscall_hook.c。整体来看KernelSU 通过内核态实现 内核白名单 可裁剪 root 特权 可插拔挂载基础设施四层架构把 root 能力从全有或全无推进到了按应用、按维度精细控制的粒度——这也是其首页四大特性相互咬合、共同构成完整设计哲学的核心所在。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考