服务进程不应以root运行，应创建专用低权限用户（如appsvc），通过User=、Group=指定，并用CapabilityBoundingSet、NoNewPrivileges等限制权限；配置文件须设600权限；禁用非必要系统账号。
服务进程不能用 root 运行
linux 服务长期以 root 身份运行，等于把整个系统钥匙交给了业务代码。一旦服务存在漏洞（比如反序列化、命令注入），攻击者直接获得最高权限。
实操建议：
- 新建专用低权限用户，例如
sudo useradd -r -s /sbin/nologin appsvc - 修改服务单元文件（
/etc/systemd/system/xxx.service），在[Service]段明确指定：User=appsvcGroup=appsvc - 确保服务工作目录、日志路径、配置文件对
appsvc可读写，但禁止其他用户访问：chmod 750 /opt/myapp、chown -R appsvc:appsvc /opt/myapp - 若服务需绑定低端口（如 80/443），不要改回
root，改用setcap 'cap_net_bind_service=+ep' /usr/bin/myapp授权单个二进制
systemd 服务中禁用 Privileged=true
很多打包脚本或旧模板会默认加 Privileged=true（实际应为 Capabilities= 或 SecureBits= 控制），这会让进程继承父进程全部能力，等同于保留 root 权限。
常见错误现象：明明设了 User=appsvc，但 ps aux | grep myapp 显示 UID=0，或 capsh --print 里仍看到 cap_sys_admin 等高危 capability。
实操建议：
- 检查
systemd服务文件中是否误用了Privileged=true（该字段并不存在于标准 systemd 中，属常见拼写/理解错误） - 真正需要能力时，用
CapabilityBoundingSet=显式声明，例如仅需网络绑定：CapabilityBoundingSet=CAP_NET_BIND_SERVICE - 加上
NoNewPrivileges=true，阻止进程后续通过execve提权 - 配合
RestrictSUIDSGID=true和RestrictNamespaces=true进一步收窄攻击面
配置文件与密钥不能被服务用户以外读取
服务以非 root 用户运行后，常有人忽略配置文件权限——比如把数据库密码写在 /etc/myapp/config.yaml，却留着 644 权限，导致任意本地用户都能 cat 出来。
使用场景：spring Boot 的 application.yml、nginx 的 ssl_certificate_key、redis 的 requirepass 配置项。
实操建议：
- 配置文件属主设为服务用户，权限收紧到
600：chown appsvc:appsvc /etc/myapp/config.yaml && chmod 600 /etc/myapp/config.yaml - 避免在命令行参数里传密钥（
myapp --password=xxx），进程列表里明文可见；改用环境变量 +EnvironmentFile=（同样要设好权限） - 敏感字段（如
password、private_key）不在 git 历史中出现，CI/CD 注入时也走 secret mount 或 vault 动态获取
特殊账号（如 sync、shutdown）必须锁定且无 shell
Linux 发行版预置的系统账号（sync、shutdown、halt、operator 等）常被忽略。它们默认有登录 shell（如 /bin/bash）或空密码，一旦被利用，可绕过应用层加固。
性能/兼容性影响：禁用这些账号不影响任何现代服务运行，systemd 已接管关机流程，sync 用户也不再用于手动同步磁盘。
实操建议：
- 检查是否存在活跃的非必要系统账号：
getent passwd | awk -F: '$3 - 对每个账号执行：
sudo usermod -s /usr/sbin/nologin -L <code>sync（-L锁定密码，-s换 shell） - 确认
/etc/shadow中对应行第二字段为*或!，表示密码不可用 - 注意：不要删掉
nobody、syslog等仍有实际用途的账号，只处理明确无功能依赖的
最易被忽略的是服务启动后动态创建的子进程——比如 Java 应用调 Runtime.exec("bash")，或 Node.js 的 child_process.spawn()，它们默认继承父进程权限。加固完主进程，还得盯住它的“孩子”。