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 服务单元中应显式裁剪：
- 在
[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）持续观察并收敛规则
