Linux应用权限边界通过身份隔离、能力裁剪、访问控制三层联动实现:一、用useradd -r -s /sbin/nologin -M -U创建专属低权限系统用户;二、systemd中设CapabilityBoundingSet等限制内核能力;三、严格绑定资源归属与最小权限,并叠加SELinux/AppArmor强制访问控制。

Linux 应用执行过程中的权限边界,不是靠“给不给 root”来划的,而是通过身份隔离、能力裁剪和访问控制三层联动实现的。核心目标是:让应用只拥有完成自身任务所必需的最小权限集,既不能越界操作,也无法被横向利用。
为服务进程分配专属低权限用户
避免应用以 root 或通用系统账户(如 daemon)运行。必须为每个服务创建独立的系统用户,且默认无登录能力:
- 用
useradd -r -s /sbin/nologin -M -U appname创建——-r标识系统用户,-s /sbin/nologin禁止 shell 登录,-M不建家目录,-U自动创建同名主组 - 确认该用户仅加入必要附加组,例如需访问磁盘设备才加
disk,需网络管理才加netadmin,其余一概不加 - 检查
/etc/passwd中该用户 shell 字段确为/sbin/nologin,且/etc/shadow中密码字段为*或!
限制进程可调用的内核能力(Capabilities)
即使以非 root 用户运行,进程仍可能通过 capability 获得高危权限。systemd 服务单元中应显式裁剪:
Linux 性能分析与调优专家,覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景:系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 在
[Service]段落中设置CapabilityBoundingSet=,只保留必需项,例如CAP_NET_BIND_SERVICE(绑定 1024 以下端口)、CAP_DAC_OVERRIDE(绕过文件读写权限检查)通常禁用 - 搭配
RestrictRealtime=yes、RestrictNamespaces=yes、NoNewPrivileges=yes进一步封堵提权路径 - 用
getpcaps $(pgrep appname)验证实际生效的能力集,确保未继承多余 capability
绑定文件与目录的归属及最小权限
服务运行所需的配置、数据、日志路径,必须严格归属其专用用户,并按需收紧权限:
- 配置文件(如
/etc/appname/conf.d/)设为640,属主为appname,属组为appname或运维组 - 数据目录(如
/var/lib/appname/)设为750,禁止 other 可访问;若仅进程自身读写,可设为700 - 日志路径(如
/var/log/appname/)设为750,并确保日志轮转脚本也以appname身份执行 - 禁止任何路径对
others开放写权限,尤其警惕777或g+w类配置
启用强制访问控制(SELinux/AppArmor)
DAC(自主访问控制)有局限,需叠加 MAC(强制访问控制)形成纵深防御:
- TencentOS、RHEL 等默认启用 SELinux,用
ls -Z查看上下文,确保服务相关文件标记正确(如system_u:object_r:appname_exec_t:s0) - 为服务编写或启用对应 SELinux 策略模块,明确定义其可读哪些配置、可写哪些日志路径、可监听哪些端口、可访问哪些 socket
- Ubuntu/Debian 环境常用 AppArmor,通过
/etc/apparmor.d/usr.bin.appname定义抽象规则,拒绝未声明的路径访问和系统调用 - 策略启用后,用
ausearch -m avc -ts recent(SELinux)或aa-logprof(AppArmor)持续观察并收敛规则

















