linux不原生支持rbac，但可通过sudo、selinux、pam与文件权限协同构建企业级最小化授权模型，核心是落实“角色抽象—权限绑定—用户指派”，在命令、进程、资源三层实现精细化控制，并配套审计、版本化与生命周期管理。
Linux 本身不区分认证与授权环节，但通过合理组合机制，完全可以实现“认证归认证、授权归授权”的分离式 RBAC 管理。关键不是替换系统登录流程，而是让身份验证（你是谁）和权限执行（你能做什么）解耦——用户用密码或密钥登录后，其后续操作能力由角色策略动态决定，而非登录 Shell 或 UID 直接赋予。
认证层：聚焦身份核验，不掺杂权限逻辑
认证只管“是不是本人”，不决定“能干啥”。应严格限制认证文件的干预范围：
- /etc/passwd 和 /etc/shadow 仅用于存储凭证和基础账户状态，禁止在其中嵌入权限字段（如 GECOS 字段不写角色名）
- 禁用 .rhosts、hosts.equiv 等弱认证方式；SSH 登录强制使用密钥+可选 MFA，关闭 PasswordAuthentication
- 若需多因素，通过 PAM 模块（如 pam_google_authenticator 或 pam_yubico）在 auth 堆栈中处理，不把 OTP 验证结果映射为 sudo 权限
- 所有用户默认使用受限 Shell（如 /bin/bash 或 /usr/bin/zsh），不设 /bin/false、/sbin/nologin 作为常规账户登录 Shell（除非明确禁止交互，如服务账户）
授权层：用角色容器承接权限，与登录身份解绑
授权必须脱离 UID/GID 的静态绑定，转为“用户→组（角色）→命令/进程域”的三级映射：
- 创建职能明确的角色组，如 netadmin、logviewer、cert-manager，组名不带“user”“dev”等模糊前缀
- 在 /etc/sudoers.d/ 下按角色建独立文件，例如 /etc/sudoers.d/rbac-logviewer，内容只含该角色所需命令别名与组绑定
- 每个角色组仅允许切换到预设目标用户（如 %logviewer ALL=(syslog) /usr/bin/journalctl），禁止 (ALL) 全局提权
- 敏感操作强制指定运行上下文：sudo -u syslog journalctl -u nginx --since "2 hours ago"
进程级隔离：补足 sudo 无法约束的行为边界
sudo 控制“能不能运行”，SELinux 控制“运行后能访问什么”。两者叠加才构成完整授权链：
- 启用 enforcing 模式：setenforce 1；确认 sestatus 输出为 “enabled” 和 “enforcing”
- 为关键角色脚本打专用类型标签，例如备份脚本 chcon -t backup_exec_t /opt/bin/db-dump.sh
- 用 sesearch 验证进程域是否越权：sesearch -A -s backup_agent_t -t etc_t -c file -p write（应拒绝）
- 拒绝用 permissive 模式“绕过问题”，所有 avc 拒绝日志需 audit2why 分析并生成最小化策略模块
审计与闭环：让每次权限变更可追溯、可验证、可回收
没有审计的 RBAC 是纸面模型。授权有效性必须靠主动探测和周期清理来保障：
- 每日执行 sudo -l -U $user > /var/log/rbac/audit-$user.log，比对基线发现隐式扩权
- 每周扫描 sudoers 语法：find /etc/sudoers* -type f -exec sudoers -c {} \;
- 每月同步 HR 系统离职名单，自动移除角色组成员：getent group netadmin | cut -d: -f4 | tr ',' '\n' | grep -v '^$' | while read u; do id "$u" &>/dev/null || gpasswd -d "$u" netadmin; done
- 所有 /etc/sudoers.d/ 文件纳入 Git 版本库，CI 流水线校验新增规则是否含 !/bin/sh、!/usr/bin/su 等防护项
