首页/安全/取证与溯源速查/服务单元环境变量与注入点
Linux 取证135 条

服务单元环境变量与注入点

unit 文件通过 Environment 与 EnvironmentFile 注入变量,指向可写目录的变量文件可被替换,从而改变服务行为。

取证与溯源速查安全更新于 2026-10-13

服务单元的环境变量注入点

systemd 单元通过 Environment 与 EnvironmentFile 两个字段向服务进程注入环境变量,覆盖代理设置、库搜索路径、监听地址等运行参数。变量文件通常是普通文本文件,如果路径落在可写目录且权限过于宽松,能写该文件的低权限用户就可以改变服务行为,例如把代理指向自己的监听端口。取证时要看单元中这两个字段的取值、变量文件的实际权限与内容,以及是否存在 drop-in 覆盖。

基本信息

关键字段Environment=、EnvironmentFile=、User=
查看命令systemctl show <服务> -p Environment -p EnvironmentFiles
覆盖机制drop-in 目录 /etc/systemd/system/<服务>.service.d/*.conf
风险点变量文件位于可写目录或权限宽松

典型使用场景

  • 排查服务行为与配置文件不一致,怀疑变量被注入
  • 核查服务以哪个用户身份运行,评估权限边界
  • 对比单元文件与 drop-in 目录,找出被覆盖的字段
  • 检查变量文件权限,判断低权限用户能否改写
  • 确认服务重启时间晚于文件改动时间,建立因果顺序

核查注入点

核查注入点
systemctl show nginx -p Environment -p EnvironmentFiles -p User 2>/dev/null
systemctl cat nginx | head -30          # 打印单元与 drop-in 的合并内容
ls -l /etc/default/nginx 2>/dev/null    # 变量文件权限,是否可被非属主写入
systemd-delta --type=extended | head -20   # 列出被覆盖的配置项
systemctl show nginx -p ExecStart        # 启动命令中是否也带环境变量

单元字段读法

字段含义判读要点
Environment单元内直接写的变量值在文件中可见,改动需重载
EnvironmentFile从外部文件读取变量文件权限决定注入风险
User服务运行身份与变量文件属主对照判断越权可能
drop-in 覆盖额外片段的取值优先级高于主单元,最易被忽略
Environment 与变量文件的改动都要在服务重启后才生效,因此进程启动时间会晚于文件修改时间,建立时间线时要按这个顺序解释而不是反过来。
查看运行中进程的实际环境可用 /proc/<pid>/environ,它反映的是服务启动那一刻的取值,与当前配置文件可能已经不同。
直接编辑 /usr/lib/systemd/system 下的发行版单元会在包升级时被覆盖,核查现场改动应重点看 /etc/systemd/system 与 drop-in 目录。

易错点

  • 只看主单元不看 drop-in,被覆盖的字段漏判
  • 变量文件权限 666 却未纳入风险清单,注入路径被忽略
  • 按文件修改时间直接解释为服务立即生效,时间线前后颠倒
  • 在生产机上直接用 systemctl edit 试改,未考虑回滚与审计留痕

数据来源与参考

  • systemd 官方文档(systemd.exec 环境变量)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌