在Ubuntu系统中，pam_env模块负责在用户会话期间加载和设置环境变量，但如果配置不当，它可能成为安全隐患——比如敏感路径信息泄露、恶意变量注入等。解决这个问题的核心方法是通过编辑/etc/environment和/etc/security/pam_env.conf文件，明确指定需要保留的白名单变量，同时清理掉所有不必要的环境变量。具体来说，你需要在pam_env.conf中使用"DEFAULT"指令设置默认行为为清除，再用"OVERRIDE"或"KEEP"指令保留必要变量，这样每次用户登录时系统会自动清理掉多余的环境变量，只留下你明确允许的那些。
很多运维人员和安全工程师在加固Ubuntu服务器时，往往忽略了环境变量这一环。实际上，Linux系统中的环境变量（如PATH、LD_LIBRARY_PATH、HOME等）如果被恶意篡改或携带敏感信息，攻击者可以利用它们实现权限提升、路径劫持甚至远程代码执行。pam_env作为PAM（Pluggable Authentication Modules）体系中的关键模块，正是控制这些变量的第一道关卡。
pam_env模块的工作原理
pam_env模块在用户认证过程中被PAM框架调用，主要执行两个操作：读取配置文件中定义的环境变量并设置到用户会话中，以及根据配置规则清理或覆盖已有的环境变量。它的配置文件通常位于/etc/security/pam_env.conf，同时/etc/environment文件也会被pam_env读取。模块支持多种指令类型，包括设置变量（VARIABLE=value）、清除变量（VARIABLE=@reset）、覆盖变量（VARIABLE OVERRIDE=value）等。
在Ubuntu的默认PAM配置中，pam_env通常在/etc/pam.d/login、/etc/pam.d/sshd、/etc/pam.d/sudo等文件中被引用。你可以用以下命令查看当前引用情况：
grep -r "pam_env" /etc/pam.d/
输出结果通常类似于：
session required pam_env.so readenv=1 user_readenv=0
这里readenv=1表示从/etc/environment和/etc/security/pam_env.conf读取变量，user_readenv=0表示不读取用户自定义的~/.pam_environment文件。这个默认配置已经做了一定的安全限制，但还远远不够。
为什么需要清理环境变量
在实际生产环境中，Ubuntu服务器上可能积累了大量无用甚至危险的环境变量。举几个典型场景：
第一，开发环境残留。如果服务器曾经用于软件开发，可能存在LD_LIBRARY_PATH指向不安全的库目录，攻击者可以通过植入恶意共享库来劫持程序执行流程。第二，多用户环境污染。在共享服务器上，不同用户可能设置了相互冲突的变量，导致不可预期的行为。第三，敏感信息暴露。某些应用程序会将数据库密码、API密钥等写入环境变量，如果这些变量在会话结束后没有被清理，后续登录的用户可能通过env命令看到这些信息。
从安全合规角度看，CIS Benchmark、STIG等安全基线都明确要求对环境变量进行最小化管理。pam_env模块的清理功能正是满足这些要求的有效手段。
配置pam_env.conf实现变量清理
编辑/etc/security/pam_env.conf文件，这是pam_env模块的核心配置文件。文件格式为每行一条规则，支持注释（以#开头）。要实现全面清理，需要遵循以下步骤：
首先，在文件开头添加默认清除指令，将所有未明确指定的变量设为清除状态：
DEFAULT @{HOME}
DEFAULT @{SHELL}
DEFAULT @{PATH}=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DEFAULT @{LANG}=en_US.UTF-8
DEFAULT @{LC_ALL}=en_US.UTF-8
# 以下变量默认清除
DEFAULT @{LD_LIBRARY_PATH}=@reset
DEFAULT @{LD_PRELOAD}=@reset
DEFAULT @{PYTHONPATH}=@reset
DEFAULT @{PERL5LIB}=@reset
DEFAULT @{RUBYLIB}=@reset
DEFAULT @{NODE_PATH}=@reset
DEFAULT @{GEM_PATH}=@reset这里的@reset表示将该变量设置为空值（即清除）。你需要根据自己服务器的实际需求，只保留必要的变量。上面的例子中，只保留了HOME、SHELL、PATH、LANG、LC_ALL这几个基本变量，其他常见的库路径变量全部清除。
如果某些特定用户或服务需要额外的变量，可以使用OVERRIDE指令为特定用户或服务单独设置：
# 为deploy用户保留特定的PATH
deploy OVERRIDE @{PATH}=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/deploy/bin
# 为sshd服务设置特定变量
sshd OVERRIDE @{LC_TIME}=en_US.UTF-8需要注意的是，OVERRIDE指令会覆盖DEFAULT的设置，所以要谨慎使用，避免无意中打开了安全缺口。
清理/etc/environment文件
/etc/environment文件是系统级环境变量配置，pam_env模块在readenv=1时会读取它。这个文件的格式更简单，每行一个"KEY=VALUE"对。清理这个文件同样重要：
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8"
把所有不必要的变量从这个文件中删除。特别要检查是否有以下危险变量：LD_LIBRARY_PATH、LD_PRELOAD、IFS、TMPDIR（指向不安全目录）等。如果发现有，立即删除或修改为安全值。
修改完成后，执行以下命令让配置立即生效：
source /etc/environment # 或者重新登录测试
验证清理效果
配置完成后，必须验证清理是否生效。用普通用户登录系统后，执行env命令查看当前环境变量：
env | wc -l
在一个干净的Ubuntu系统中，经过合理清理后，env输出的变量数量应该控制在10-15个以内。如果仍然有几十个变量，说明配置有遗漏。
还可以用以下命令检查特定危险变量是否已被清除：
env | grep -E "LD_|PRELOAD|IFS|TMPDIR|PYTHONPATH"
如果没有任何输出，说明这些危险变量已被成功清理。同时，可以用sudo -i切换到root环境，检查root用户的环境变量是否也遵循了同样的清理规则。
针对不同服务的差异化配置
在实际运维中，不同的服务可能有不同的环境变量需求。比如，Web服务器可能需要特定的语言环境变量，数据库客户端可能需要特定的库路径。这时候不能一刀切地全部清除，而是要针对不同PAM服务配置文件做差异化处理。
查看/etc/pam.d/sshd的配置，你可能会看到：
session required pam_env.so readenv=1 envfile=/etc/default/locale
这里指定了envfile参数，意味着sshd会话会额外读取/etc/default/locale文件。你需要确保这个文件中也没有危险变量。对于sudo服务，检查/etc/pam.d/sudo：
session required pam_env.so readenv=1 user_readenv=0 envfile=/etc/default/locale
sudo的配置通常和sshd类似，但要特别注意sudo可能会保留一些额外的变量（如SUDO_USER、SUDO_UID等），这些是正常的，不需要清除。关键是确保没有LD_PRELOAD之类的危险变量通过sudo传递。
自动化检测与持续监控
手动配置一次并不意味着万事大吉。建议编写一个简单的Shell脚本，定期检测环境变量状态：
#!/bin/bash
# 检查危险环境变量
DANGEROUS_VARS=("LD_LIBRARY_PATH" "LD_PRELOAD" "IFS" "PYTHONPATH" "PERL5LIB" "RUBYLIB")
for var in "${DANGEROUS_VARS[@]}"; do
value=$(env | grep "^${var}=" | cut -d'=' -f2-)
if [ -n "$value" ]; then
echo "[ALERT] $var is set to: $value"
fi
done
# 检查变量总数
VAR_COUNT=$(env | wc -l)
if [ $VAR_COUNT -gt 20 ]; then
echo "[WARNING] Total environment variables: $VAR_COUNT (expected <= 20)"
fi将这个脚本加入crontab定期执行，或者集成到监控系统中，可以持续确保环境变量的安全性。同时，建议在系统审计日志中记录pam_env的执行情况，便于事后追溯。
常见误区和注意事项
在实践中，有几个常见误区需要避免。第一，不要盲目清除PATH变量。PATH是系统正常运行的基础，清除它会导致几乎所有命令无法执行。正确做法是设置一个安全的最小PATH。第二，不要忽略用户自定义文件。虽然默认配置中user_readenv=0禁止了~/.pam_environment，但如果有人手动修改了PAM配置启用了它，那么用户级别的变量也会生效。第三，修改配置前务必备份，pam配置出错可能导致无法登录系统，这时候需要通过单用户模式或救援模式修复。
另外，对于容器化环境（如Docker运行在Ubuntu上），pam_env的行为可能有所不同，因为容器通常不走完整的PAM认证流程。但如果你在容器内运行需要PAM认证的服务，同样需要关注这个问题。
总结与最佳实践
Ubuntu安全加固中，pam_env模块的环境变量清理是一个容易被忽视但非常重要的环节。最佳实践包括：只保留必要的白名单变量、明确清除所有库路径和语言运行时路径变量、针对不同服务做差异化配置、定期自动化检测、保持配置文件的版本管理。通过这些措施，你可以有效降低环境变量相关的安全风险，让Ubuntu系统的安全基线更加坚固。记住，安全不是一次性的工作，而是持续的过程，pam_env的配置也需要随着系统用途的变化而动态调整。
