KernelSU App Profile 完全指南：基于最小特权原则精细化管控 root 权限-北京尧图网络

KernelSU App Profile 完全指南基于最小特权原则精细化管控 root 权限【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUApp Profile 是 KernelSU 提供的应用级配置机制让 root 权限的授予不再局限于给或不给的二元选择。对已授权 root 的应用它可通过 Root Profile 自定义su进程的 uid、gid、groups、capabilities 与 SELinux 域实现防火墙只联网、冻结应用只有 shell 权限等按需授权对普通应用它可通过 Non-Root Profile 控制内核与模块系统对该应用的可见行为如是否卸载 overlayfs 模块。读完本文你将掌握 App Profile 的数据结构、内核侧执行链路、配置语义以及如何规避提权escalation风险并设计白名单/黑名单式的模块卸载策略。一、App Profile 是什么App Profile 是 KernelSU 提供的一种机制用于针对不同应用定制化其配置。它分为两大类Root Profile作用于已被授予 root 权限即可使用su的应用。它允许自定义su命令执行后的uid、gid、groups、capabilities和SELinux规则从而限制 root 用户的特权。例如只给防火墙应用授予网络权限而拒绝文件访问权限或者只给冻结类应用授予 shell 权限而不是完整 root 权限。其核心设计理念是让权力始终受控于最小特权原则principle of least privilege。Non-Root Profile作用于没有 root 权限的普通应用。它可以控制内核与模块系统对这些应用的行为例如决定由模块产生的系统修改overlayfs 挂载是否要对某个应用隐藏。两个 Profile 的关系在 kernel/policy/allowlist.c 中有直观体现内核缓存了default_root_profile与default_non_root_profile两个默认配置app_profile结构体则通过联合体union同时容纳 root 侧与非 root 侧的配置。1.1 App Profile 的数据结构KernelSU 通过 uapi/app_profile.h 定义了内核与用户态共享的 Profile 数据结构这是整个机制的地基struct root_profile { __s32 uid; __s32 gid; __u32 groups_count; __s32 groups[KSU_MAX_GROUPS]; // KSU_MAX_GROUPS 32 struct { __u64 effective; __u64 permitted; __u64 inheritable; } capabilities; char selinux_domain[KSU_SELINUX_DOMAIN]; // 64 字节 __s32 namespaces; __u64 flags; }; struct non_root_profile { bool umount_modules; }; struct app_profile { __u32 version; // 当前 KSU_APP_PROFILE_VER 4 char key[KSU_MAX_PACKAGE_NAME]; // 通常是应用包名特殊应用可为其他值 __s32 curr_uid; bool allow_su; union { struct { bool use_default; char template_name[KSU_MAX_PACKAGE_NAME]; struct root_profile profile; } rp_config; struct { bool use_default; struct non_root_profile profile; } nrp_config; }; };关键约束摘自头文件注释与 allowlist.c 的校验逻辑包名最长 256 字节KSU_MAX_PACKAGE_NAMESELinux 域最长 64 字节KSU_SELINUX_DOMAINLinux 的NGROUPS_MAX通常是 65535但 KernelSU 只支持32 个 supplementary groupsKSU_MAX_GROUPScapabilities采用 capabilities v3 的布局kernel_cap_t即u32[2]这里用三个__u64分别表示 effective / permitted / inheritable 三个集合rp_config.use_default/nrp_config.use_default表示该应用是否使用内核内置的默认 Profiletemplate_name字段用于引用模板 Profile由 ksud 保存模板数据见下节。在用户态管理器KernelSU Manager通过 Natives.kt 中的Profiledata class 与内核交互字段一一对应allowSu、rootUseDefault、uid、gid、groups、capabilities、context、namespace、nonRootUseDefault、umountModules、flags等。其中rules字段SELinux 规则文本并不下发到内核而是保存在 ksud用户态守护进程中。1.2 默认 Profile当某个 UID 没有显式配置时内核使用init_default_profiles()见 allowlist.c初始化的默认配置default_root_profile.uid 0; // root default_root_profile.gid 0; // root 组 default_root_profile.groups_count 1; default_root_profile.groups[0] 0; // capabilities.effective CAP_FULL_SET即完整能力集 default_root_profile.namespaces KSU_NS_INHERITED; // selinux_domain u:r:ksu:s0KSU_DEFAULT_SELINUX_DOMAIN default_non_root_profile.umount_modules true; // 默认卸载模块也就是说默认 Root Profile 是完整权限的 rootuid/gid0、完整 capabilities、u:r:ksu:s0域、继承挂载命名空间默认 Non-Root Profile 会卸载模块umount modules 默认开启。这正对应文档中管理器设置界面的 Umount modules by default 开关默认开启的行为——从源码看该开关直接写入default_non_root_profile.umount_modulesallowlist.c由特殊保留 UID9999与 key$标识。二、Root Profile按需裁剪 root 的能力集Root Profile 允许自定义su后 root 进程的五个维度UID/GID/Groups、Capabilities、SELinux 域、命名空间与标志位。内核在su提权时通过 escape_with_root_profile() 统一落地。2.1 UID、GID 与 Groups身份即权限Linux 系统有两个核心概念用户user与组group。每个用户有唯一的用户 IDUID一个用户可属于多个组每个组有组 IDGID。UID/GID 用于标识系统用户并决定其可访问的系统资源。UID 为0的用户称为 root 用户GID 为0的组称为 root 组root 用户组通常拥有最高系统特权。在 Android 中每个应用共享 UID 除外都是一个独立用户拥有唯一 UID。例如0表示 root1000表示system2000表示 ADB shell10000–19999表示普通应用。需要注意这里说的 UID 与 Android 的多用户multiple users或工作资料Work profile不是一回事。工作资料是通过划分 UID 区间实现的例如10000-19999代表主用户而110000-119999代表工作资料其中的每个普通应用仍然有自己独立的 UID。这一约定在内核侧由PER_USER_RANGE100000等宏体现见 allowlist.h。每个应用可有多个组GID 表示主组primary group通常与 UID 一致其余为附加组supplementary groups。部分权限通过组来控制例如网络访问或蓝牙访问。在 ADB shell 中执行id命令可直观看到这些信息oriole:/ $ 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:s0这里 UID 是2000GID主组也是2000同时还属于若干附加组例如inet表示可创建AF_INET与AF_INET6套接字和sdcard_rw表示对 SD 卡的读写权限。Root Profile 的用法例如将某 root 应用的 UID 设为2000则它使用su时实际权限只有 ADB shell 级别再移除inet组即可阻止su访问网络。内核侧的组设置逻辑在 setup_groups()当groups_count 1 groups[0] 0时直接切换到 root 组并提前返回否则分配group_info、逐项校验 GID 有效性gid_valid、排序并set_groups()到新的 cred 上。重要边界文档明确强调App Profile 只控制su之后 root 进程的权限不控制应用自身的权限。如果应用已在系统层面申请了网络权限那么它不使用su也能访问网络从su移除inet组只阻止su访问网络。内核强制执行Root Profile 在内核中强制实施不依赖 root 应用的自愿配合。与通过su切换用户/组不同su权限的授予完全由用户而非开发者控制。提权入口escape_with_root_profile()会重新分配凭据prepare_creds/commit_creds、按 Profile 设置四组 UID/GIDuid/suid/euid/fsuid与gid/sgid/egid/fsgid、刷新cred-user与ucounts的进程计数归属并同步更新线程组的 tracepoint 标记。2.2 Capabilities把全知全能拆成可独立开关的单元Capabilities 是 Linux 的权限分离privilege separation机制。在做权限检查时传统 UNIX 将进程分为两类特权进程有效用户 IDeffective UID为 0超级用户/root绕过内核所有权限检查非特权进程有效 UID 非 0需基于进程凭证通常为有效 UID、有效 GID 与附加组列表接受完整权限检查。从 Linux 2.2 起Linux 把传统上与超级用户绑定的特权拆分为独立的单元——capabilities每个 capability 可被独立启用或禁用每个 capability 代表一个或多个特权。例如CAP_DAC_READ_SEARCH表示绕过文件读取权限检查以及目录读/执行权限检查的能力如果一个有效 UID 为0root的用户缺少CAP_DAC_READ_SEARCH或更高capability那么即使他是 root也不能随意读取文件。Root Profile 允许自定义su之后 root 进程的 capabilities从而实现部分 root 权限的授予。与 UID/GID 不同某些 root 应用必须使用 UID0此时为这个 UID 为0的 root 用户限制 capabilities就可以限制其被允许执行的操作。强烈建议Linux 的 capabilities(7) 官方手册详细解释了每个 capability 代表的能力若要自定义 capabilities务必先阅读该文档。此处链接为文档内原始外部引用仅供理解不构成对仓库内容的引用。内核侧落地方式app_profile.cProfile 中的effective能力集被同时写入新 cred 的cap_effective、cap_permitted与cap_bsetbounding set。也就是说su进程的能力上限完全由 Profile 决定——被裁剪掉的能力在任何情况下都无法再获得。2.3 SELinux默认拒绝的细粒度访问控制SELinux 是一种强大的强制访问控制Mandatory Access Control, MAC机制遵循默认拒绝原则任何未被显式允许的动作都会被拒绝。SELinux 有两种全局模式宽容模式Permissive mode拒绝事件被记录但不执行强制模式Enforcing mode拒绝事件被记录并执行。警告文档原文现代 Android 系统高度依赖 SELinux 来保证整体系统安全。强烈建议不要使用任何运行在宽容模式下的自定义系统因为与完全开放的系统相比它没有任何显著优势。SELinux 的完整概念非常复杂超出了本文档的讨论范围建议先通过以下资源理解其工作机制文档内提供的参考资料Wikipedia: Security-Enhanced Linux、Red Hat: What Is SELinux?、ArchLinux Wiki: SELinux。Root Profile 允许自定义su后 root 进程的 SELinux 上下文。典型场景下应用执行su后进程会切换到无限制访问的 SELinux 域如u:r:ksu:s0对应源码中KERNEL_SU_CONTEXT见 selinux.h通过 Root Profile 可将该域切换到自定义域例如u:r:app1:s0并为该域定义一系列规则type app1 enforce app1 typeattribute app1 mlstrustedsubject allow app1 * * *注意allow app1 * * *仅为演示用途。实际使用中不应广泛采用这条规则因为它与宽容模式几乎没有区别。内核通过 setup_selinux()声明见 selinux.h在提权时写入selinux_domain且校验逻辑要求该域非空、长度小于 64 字节allowlist.c。2.4 命名空间与其他字段除了文档重点讲解的 UID/GID/Groups、Capabilities、SELinux 之外root_profile还包含两个字段可结合源码一并理解namespaces挂载命名空间模式取值定义在 su_mount_ns.hKSU_NS_INHERITED(0) 继承、KSU_NS_GLOBAL(1) 全局、KSU_NS_INDIVIDUAL(2) 独立。提权末尾会调用setup_mount_ns(profile-namespaces)app_profile.c。flags目前仅定义FLAG_KSU_NO_NEW_PRIVS1ULL 0app_profile.h对应下方提权防护一节。2.5 提权风险Escalation与 NO_NEW_PRIVS 防护如果 Root Profile 配置不当可能发生提权escalation场景Root Profile 施加的限制意外失效。举例说明文档给出的典型场景假如你把 root 权限授予了 ADB shell 用户这很常见然后又给某个普通应用授予 root 权限但将其 Root Profile 的 UID 配置为2000即 ADB shell 用户的 UID那么该应用可以通过执行两次su获得完整 root 权限第一次执行su受 App Profile 约束切换到 UID2000ADB shell而非0root第二次执行su由于当前 UID 是2000而配置中已经给 UID2000ADB shell授予了 root 权限应用将获得完整 root 权限。防护手段可以在自定义 App Profile 中启用NO_NEW_PRIVS标志即FLAG_KSU_NO_NEW_PRIVS。启用后内核在提权完成时通过set_thread_flag(TIF_KSU_DISABLE_ESCAPE_WITH_ROOT)设置线程标志见 app_profile.c 与 app_profile.h当该标志存在时后续的escape_with_root_profile()会直接拒绝再次提权app_profile.c。务必注意文档强调该标志只阻止 KernelSU 为进程再次提升权限进程仍可通过其他 Linux 机制逃逸。因此请对你的权限设置保持极度谨慎。在内核 supercall 层还提供了KSU_IOCTL_DISABLE_ESCAPE_TO_ROOT命令dispatch.croot 会话可直接调用以禁止后续通过su再次提权作为对 Profile 标志的补充手段。三、Non-Root Profile对普通应用隐藏系统修改3.1 Umount Modules两种工作模式KernelSU 提供 systemless无系统修改机制来修改系统分区其实现依赖 overlayfs 挂载。然而某些应用对这种行为很敏感例如会检测 root 的金融/银行类应用。为此可以通过设置Umount modules选项为这些应用卸载已挂载的模块。管理器设置界面还提供了Umount modules by default开关默认开启——这意味着默认情况下 KernelSU或某些模块会为应用卸载模块除非额外设置。如果你不喜欢该默认设置或它影响了某些应用你有两种选择白名单模式保持Umount modules by default开启并在 App Profile 中针对需要加载模块的应用单独关闭Umount modules选项黑名单模式关闭Umount modules by default并在 App Profile 中针对需要卸载模块的应用单独开启Umount modules选项。从源码看ksu_uid_should_umount(uid)allowlist.c完整实现了这一决策树管理器自身ksu_get_manager_appid()匹配的 UID永不卸载模块没有 App Profile 的应用 → 使用default_non_root_profile.umount_modules已授予su的应用 → 不卸载res false有 Non-Root Profile 的应用 →use_default时跟随默认值否则使用 Profile 中显式配置的umount_modules。该决策通过KSU_IOCTL_UID_SHOULD_UMOUNTioctl 暴露给用户态查询dispatch.c。内核版本差异文档重要提示在内核版本 5.10 及以上的设备上内核本身会执行模块的卸载无需额外动作在内核版本低于 5.10的设备上这个开关只是纯粹的配置项KernelSU 本身不采取任何行动若要在 5.10 之前的内核上使用该选项需要将fs/namespace.c中的path_umount函数反向移植backport。某些模块如 Zygisksu也会读取该开关来判断是否需要卸载模块。3.2 Profile 的存储与加载App Profile 在内核中通过哈希表allow_list见 allowlist.c以 UID 为键维护并通过/data/adb/ksu/.allowlist文件持久化写入ksu_persistent_allow_list()以魔数0x7f4b5355 版本号逐个app_profile结构体的二进制格式落盘allowlist.c读取ksu_load_allow_list()校验魔数与版本当前FILE_FORMAT_VERSION 4并支持从旧版本2/3迁移例如把u:r:su:s0域迁移为u:r:ksu:s0、为 v3 自动补上FLAG_KSU_NO_NEW_PRIVSallowlist.c清理ksu_prune_allowlist()在开机完成后删除已卸载应用的记录保留 UID9999与1053WebView zygote等特殊条目allowlist.c。用户态管理器通过KSU_IOCTL_GET_APP_PROFILE/KSU_IOCTL_SET_APP_PROFILE两个 ioctl 读写 Profiledispatch.c且这两个命令只允许管理器manager调用映射表中perm_check only_manager。设置成功后内核会立即持久化并刷新运行中进程的标记。四、与模块系统的协作模板 Profile 与规则下发App Profile 还支持**模板Template**复用rp_config.template_name指向一个具名模板模板的实际内容由 ksud 保存管理器 UI 中的TemplateConfig组件见 ProfileConfig.kt。Profile 中的rules字段SELinux 规则文本也不会下发给内核而是由 ksud 负责解析并注入内核的 sepolicy经由KSU_IOCTL_SET_SEPOLICY的handle_sepolicy()处理dispatch.c。这意味着自定义 SELinux 域配套规则的整体方案是管理器把规则交给 ksudksud 编译/注入规则内核在执行su时按 Profile 切换到对应域。同时KernelSU 的 feature 机制feature.c允许内核与模块注册/查询/设置能力开关KSU_IOCTL_GET_FEATURE/KSU_IOCTL_SET_FEATURE模块可以据此感知Umount modules by default等全局配置并调整自身行为——这正是文档所述某些模块会使用该开关判断是否需要卸载模块的底层通道。五、实践建议与配置清单基于文档与源码整理一份安全配置清单配置项位置建议uid / gid / groupsRoot Profile按最小特权原则设置不要轻易把普通应用配成其他已授权 UID防提权capabilitiesRoot Profile仅保留应用必需能力修改前阅读 capabilities(7) 手册selinux_domainRoot Profile定义独立域并配套最小化 allow 规则避免allow app1 * * *NO_NEW_PRIVS 标志Root Profile flags强烈建议开启阻断经su的二次提权umount_modulesNon-Root Profile配合全局默认开关选择白名单或黑名单策略template_nameRoot Profile复用模板保持配置一致性核心要点回顾App Profile 的默认 Root Profile 是完整 root默认 Non-Root Profile 卸载模块umount_modules true一切定制都从这两份默认配置出发Root Profile 在内核escape_with_root_profile()中强制执行覆盖 UID/GID/Groups、capabilitieseffective/permitted/bounding set、SELinux 域、命名空间与 flags不依赖应用的自觉性配置不当存在二次su提权风险NO_NEW_PRIVS只能阻断 KernelSU 通道的提权权限设计仍需谨慎Umount modules在 5.10 以下内核仅是配置项需自行 backportpath_umount在 5.10 及以上内核由内核实际执行模块可通过 feature 机制读取该配置调整行为。如需进一步深入可继续阅读仓库中的 uapi/app_profile.h数据结构、kernel/policy/app_profile.c提权实现、kernel/policy/allowlist.c默认配置/持久化/卸载决策以及管理器侧的 Natives.kt用户态 Profile 模型与 AppProfileConfig配置界面入口。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

KernelSU App Profile 完全指南：基于最小特权原则精细化管控 root 权限

相关推荐

大白话说Spring全家桶-07-Bean注册

GOAP 性能瓶颈与缓存规划：避免每帧重复求解动作图

Java点餐系统源码实战：订单状态机、支付回调与Android联调

更多资讯

AI时代高薪风口：小白也能收藏的进阶指南，抓住大模型机遇！

Android移动办公系统在汽车4S店的应用与实现

Helm从入门到精通：Kubernetes包管理实战指南

小白程序员看过来！收藏这份AI应用开发入门指南，轻松入行大模型赛道！

大模型小白必看：收藏这份企业级AI Agent中台搭建指南，轻松实现数字员工自主执行！

【UNIVER实验室】DIC中的立体匹配和时序匹配(1)

今日更新

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？