systemd-analyze security 命令可评估服务安全暴露等级（0–10分），分数越低限制越严；它仅适用于服务单元，输出中 ✗ 表示缺失关键沙箱配置，需结合服务职责判断是否必须修复。
直接用 systemd-analyze security 命令就能评估服务的安全受限等级，它会逐项检查沙箱类配置并给出暴露分（0–10分），分数越低代表限制越严、安全性越高。生产环境不建议全盘依赖默认评分，而应结合服务实际职责判断哪些“不安全项”可接受、哪些必须修复。
运行分析命令并理解输出含义
执行命令格式为：
systemd-analyze security [service-name]例如检查关键服务：
systemd-analyze security sshd.service输出中每行包含一个安全配置项，带 ✗ 表示该配置缺失或设置宽松，影响暴露等级；✓ 或无标记表示已启用合理限制。重点关注以下几类：
- User= / DynamicUser=：未指定非特权用户，服务以 root 运行 → 高风险
- NoNewPrivileges=：未启用时，进程可调用 execve 提权 → 必须开启
- CapabilityBoundingSet=~CAP_*：未移除无关能力（如 CAP_SYS_TIME、CAP_NET_ADMIN）→ 按需裁剪
- PrivateTmp= / PrivateDevices= / ProtectHome= / ProtectSystem=：任一未启用都会扩大攻击面
- RestrictAddressFamilies= / SystemCallFilter=：深度隔离项，生产核心服务建议启用
识别真实风险，区分“必要宽松”与“可修复漏洞”
不是所有 ✗ 都要立即修复。比如 NetworkManager.service 必须访问网络设备和系统时钟，CapabilityBoundingSet=~CAP_SYS_TIME 和 PrivateDevices=false 是功能所需，强行收紧会导致服务不可用。但以下情况属于典型可修复项：
- 数据库服务（如 postgresql.service）仍以 root 启动，却未设 User=postgres
- Web 应用服务（如 nginx.service）未启用 PrivateTmp=true，临时文件可能被其他进程读写
- 日志收集服务（如 rsyslog.service）未设 NoNewPrivileges=true，存在二进制提权路径
判断依据是：该服务是否真的需要对应权限？能否通过改用非 root 用户、拆分功能模块、或加装 seccomp 过滤器来替代？
批量扫描与持续监控方法
对生产系统做全覆盖检查，可用如下方式快速定位高风险服务：
systemctl list-unit-files --type=service --state=enabled | awk '{print $1}' | xargs -I{} systemd-analyze security {} 2>/dev/null | grep "Overall exposure level"结果按暴露分排序后，优先处理暴露分 ≥8.0 的服务。更稳妥的做法是配合脚本定期运行：
- 将 systemd_scan.sh（konstruktoid/hardening 项目提供）部署到 cron，每周生成安全基线报告
- 在 CI/CD 流水线中集成 systemd-analyze verify + security 双校验，确保新上线服务单元符合安全策略
- 把关键服务的 exposure level 写入 Prometheus，用 Grafana 做趋势监控，异常升高即告警
修复后验证配置生效
修改 .service 文件后，必须重载并确认配置加载成功：
- 编辑单元文件后运行：sudo systemctl daemon-reload
- 重启服务：sudo systemctl restart servicename.service
- 验证运行时效果：systemctl show servicename.service | grep -E "(User|NoNewPrivileges|PrivateTmp)"
- 检查进程实际能力：sudo cat /proc/$(pgrep -f servicename)/status | grep CapEff
注意：部分配置（如 DynamicUser=）需服务完全停止再启动才生效，不能仅 reload。
