Debian系统服务权限安全管控实操指南

在Debian生产环境中，最容易被忽视的往往不是零日漏洞，而是服务运行时的权限配置。一个以root身份运行的Web应用，一旦被攻破，攻击者就能直接获得整台服务器的控制权。权限管控不是简单的“不用root”，而是一套贯穿服务生命周期的防御体系。

Debian系统中，每个进程都有实际用户ID（UID）、有效用户ID（EUID）、文件系统用户ID（FSUID）以及对应的组ID。服务启动时，父进程的权限会传递给子进程。这意味着，如果你用root启动了一个服务，而该服务没有主动降权，它的所有子进程都将以root身份运行。实际场景中，攻击者通过一个上传漏洞写入Webshell，这个Webshell继承的就是Web服务进程的权限。如果Web服务是root，攻击者就能直接读写/etc/shadow文件。

查看当前系统所有进程的权限分布，可以用这条命令快速排查高风险进程：

ps aux | awk '$1=="root" && $11!~/^\[/{print $2,$11}'

这条命令会列出所有以root运行且非内核线程的进程，输出结果中如果出现nginx、mysql、redis等应用服务，就需要立即整改。

绝大多数Linux服务都支持在配置文件中指定运行用户和组。以Nginx为例，在/etc/nginx/nginx.conf中，worker_processes配置项下方通常有user指令：

user www-data;

修改后需要确保/var/log/nginx、/var/cache/nginx等目录的属主与www-data一致，否则服务重启后会因无法写入日志而启动失败。执行以下命令修正目录权限：

chown -R www-data:www-data /var/log/nginx /var/cache/nginx

对于MySQL或MariaDB，安装后默认会创建mysql用户，但部分运维人员为了方便，会用root直接启动mysqld。正确的做法是检查/etc/mysql/my.cnf中的user配置项：

[mysqld]
user=mysql

Redis的默认配置文件/etc/redis/redis.conf中，通常没有显式设置运行用户。很多Redis入侵事件就是因为Redis以root身份运行，攻击者通过未授权访问直接写SSH公钥到/root/.ssh/authorized_keys。务必在配置文件中添加：

user redis

同时将Redis数据目录和日志目录的属主改为redis用户。

Debian从8版本开始全面采用systemd，服务启动的权限控制可以在unit文件中精细定义。以自定义的Python Web应用为例，/etc/systemd/system/myapp.service文件可以这样编写：

[Unit]
Description=My Python Web Application
After=network.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/python /opt/myapp/app.py
Restart=on-failure
RestartSec=5s
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/log/myapp /var/lib/myapp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

这里有几个关键的安全指令需要深入理解。NoNewPrivileges=yes阻止进程及其子进程通过setuid或setgid程序提权。PrivateTmp=yes为服务分配独立的/tmp目录，防止通过临时文件进行攻击。ProtectSystem=strict将整个文件系统挂载为只读，只有ReadWritePaths指定的路径可写。如果你的应用需要绑定低于1024的端口，传统做法需要root启动后降权，但通过CapabilityBoundingSet=CAP_NET_BIND_SERVICE，可以直接赋予非root用户绑定特权端口的能力，无需任何降权逻辑。

创建服务对应的系统用户时，使用如下命令确保用户没有登录Shell：

useradd -r -s /usr/sbin/nologin -d /opt/myapp -M myapp

-r参数创建系统用户，-s指定不可登录的Shell，-M不创建家目录，最大程度减少攻击面。

传统的ugo权限模型在复杂场景下捉襟见肘。比如你有三个服务，分别需要读取同一个日志目录，但只有其中一个能写入。这时就需要ACL（访问控制列表）。首先确认文件系统已挂载acl选项，Debian默认的ext4和xfs都支持。使用getfacl查看目录当前的ACL：

getfacl /var/log/myapp

设置ACL让logreader用户只读，logwriter用户可读写：

setfacl -m u:logreader:rx /var/log/myapp
setfacl -m u:logwriter:rwx /var/log/myapp

ACL的默认继承属性同样重要。设置目录的默认ACL，使新建文件和子目录自动继承权限：

setfacl -d -m u:logreader:r /var/log/myapp

在实际安全加固中，ACL可以解决很多“不得不给777权限”的无奈场景，将权限控制在最小必要范围内。

Linux将root的超级权限拆分成多个独立的能力（capabilities），服务只需要获得它真正需要的几个能力，而不是完整的root权限。例如，一个需要监听80端口的服务，只需要CAP_NET_BIND_SERVICE。一个需要发送信号的监控服务，只需要CAP_KILL。通过systemd的AmbientCapabilities指令可以授予能力：

AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SYS_NICE

更严格的方案是使用CapabilityBoundingSet限制进程能获得的最大能力集合，结合AmbientCapabilities只授予当前需要的能力。查看某个进程当前拥有的能力：

cat /proc/PID/status | grep -i cap

输出的十六进制掩码可以用capsh工具解码：

capsh --decode=00000000000004c0

AppArmor是Debian默认启用的强制访问控制框架，它比SELinux更简洁。检查当前AppArmor状态：

aa-status

为服务编写AppArmor配置文件，以MySQL为例，/etc/apparmor.d/usr.sbin.mysqld文件定义了mysqld能访问的文件路径和能力。编写完成后加载：

apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld

AppArmor的complain模式可以先记录违规行为而不阻断，用aa-logprof工具分析日志后自动生成策略，大大降低了配置门槛。

即使使用Docker或Podman，容器内进程的权限管控同样不能忽视。很多开发者习惯在Dockerfile中写USER root，然后忘了切回普通用户。容器默认的root虽然受namespace隔离，但一旦结合--privileged或挂载宿主机敏感目录，风险会急剧放大。在Dockerfile中明确指定用户：

FROM debian:bookworm
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
USER appuser
CMD ["/app/service"]

运行容器时，通过--user参数覆盖默认用户，通过--cap-drop去掉所有能力，再用--cap-add只加回必要的：

docker run --user 1000:1000 --cap-drop=ALL --cap-add=NET_BIND_SERVICE -d myimage

对于Podman，它支持rootless模式，整个容器运行时都不需要root权限，这是更安全的选择。在Debian上安装Podman后，普通用户直接运行容器即可，无需sudo。

权限配置不是一次性工作，系统更新、服务升级、配置变更都可能引入新的权限问题。使用auditd监控关键文件的权限变化，在/etc/audit/rules.d/audit.rules中添加规则：

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/systemd/system/ -p wa -k systemd_units

重启auditd后，任何对这些文件的写操作或属性修改都会被记录。定期用ausearch查询审计日志：

ausearch -k identity --start today

结合systemd的日志分析，快速定位异常权限变更：

journalctl _UID=0 --since "1 hour ago" | grep -i "start\|stop\|restart"

这条命令列出过去一小时内所有root用户发起的服务启停操作，任何非预期的服务重启都应引起警觉。

定期执行自动化权限审计脚本，将以下检查项写成cron任务：扫描所有监听端口的进程及其运行用户，检查/etc/passwd中UID为0的账户，查找全局可写的配置文件和目录，验证关键系统二进制文件的完整性。将这些检查结果输出到集中日志平台，形成持续改进的闭环。