Linux限制su的几种常用方法小结

引言

在 Linux 系统中，su 命令允许用户以另一个用户（通常是 root）的身份运行命令或切换用户环境。尽管 su 提供了便利，但在安全性敏感的环境中，允许任意用户通过 su 切换到 root 或其他特权用户可能会带来严重的安全风险。为了增强系统安全性，Linux 提供了多种手段来限制 su 命令的使用。本文将深入探讨几种常见的限制 su 的方法，包括 NoNewPrivileges 设置、PAM（Pluggable Authentication Modules）配置、Wheel 组限制、以及其他相关技术手段。

一、背景：为什么需要限制 su 命令？

su 命令（substitute user）是 Linux 系统中用于切换用户身份的常用工具。通过执行 su - 命令并输入目标用户的密码，用户可以切换到目标用户的环境（通常是 root）。然而，这种机制存在以下安全隐患：

1. 密码泄露风险：如果 root 密码被泄露，任何知道密码的用户都可以通过 su 切换到 root，执行任意操作。
2. 权限提升漏洞：某些程序可能利用 su 或 setuid 机制提升权限，导致非授权用户获取特权。
3. 误操作风险：普通用户切换到 root 后，可能因误操作导致系统配置错误或数据丢失。
4. 安全审计难度：未受限的 su 使用可能导致难以追踪的操作记录，增加安全审计的复杂性。

因此，限制 su 的使用是 Linux 系统安全加固的重要一环。以下将详细介绍几种常见的限制手段。

二、限制 su 的手段一：使用 NoNewPrivileges 设置

1. NoNewPrivileges 的作用

NoNewPrivileges 是 systemd 提供的一项安全功能，用于限制进程及其子进程获得新的特权。启用 NoNewPrivileges 后，进程将无法通过 execve(2) 系统调用、setuid/setgid 文件权限或其他机制提升权限。这对于限制 su 命令的执行非常有效，因为 su 通常依赖 setuid 位来切换用户身份。

NoNewPrivileges 的主要特点包括：

• 禁止特权提升：防止进程通过 setuid/setgid 或文件系统能力（capabilities）获得额外的特权。
• 影响范围：不仅限制当前进程，还限制其所有子进程。
• 适用场景：适用于运行不受信任程序的 systemd 服务，如 Web 服务器、数据库服务等。

2. 配置 NoNewPrivileges

在 systemd 单元文件中，可以通过设置 NoNewPrivileges=yes 来启用此功能。以下是一个配置示例，针对 sshd 服务：

# 编辑 sshd 服务单元文件
sudo systemctl edit ssh.service

在编辑器中添加以下内容：

[Service]
NoNewPrivileges=yes

保存后，重新加载 systemd 配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart ssh.service

可以通过以下命令验证 NoNewPrivileges 设置是否生效：

systemctl show --property=NoNewPrivileges ssh.service

输出结果应为：

NoNewPrivileges=yes

3. NoNewPrivileges 对 su 的限制效果

当 NoNewPrivileges 设置为 yes 时，su 命令在受限进程中将无法提升权限。例如，如果某个服务以非特权用户运行，并尝试通过 su 切换到 root，用户将收到权限拒绝的错误。这是因为 su 的 setuid 位被 NoNewPrivileges 限制，无法执行特权操作。

4. 优缺点分析

优点：

• 简单易用，只需修改 systemd 单元文件。
• 提供强大的特权控制，适用于服务级别的安全加固。
• 对子进程的限制确保了特权控制的全面性。

缺点：

• 仅适用于 systemd 管理的服务，无法直接限制用户登录会话中的 su 命令。
• 可能影响需要特权操作的合法进程，需仔细测试。

适用场景：适合对特定服务（如 Web 服务器、容器化应用）进行沙箱化限制，但不适合限制用户直接通过终端运行 su。

三、限制 su 的手段二：PAM 配置与 Wheel 组

1. PAM 认证机制简介

PAM（Pluggable Authentication Modules）是 Linux 系统中用于认证和授权的模块化框架。su 命令的认证流程由 /etc/pam.d/su 文件控制。通过修改 PAM 配置文件，可以限制哪些用户能够使用 su 命令。

2. 使用 Wheel 组限制 su

在 Linux 系统中，wheel 组是一个特殊的管理员组，通常用于限制特权操作。可以通过配置 PAM 和 /etc/login.defs 文件，只允许 wheel 组成员使用 su 切换到 root。

配置步骤

启用 pam_wheel 模块：
编辑 /etc/pam.d/su 文件，找到以下行并取消注释（移除行首的 #）：

#auth required pam_wheel.so use_uid

修改为：

auth required pam_wheel.so use_uid

这一行表示只有 wheel 组的用户才能通过 su 认证。

配置 /etc/login.defs：
编辑 /etc/login.defs 文件，添加以下行：

SU_WHEEL_ONLY yes

这要求只有 wheel 组成员才能使用 su 切换到 root。

将用户添加到 wheel 组：
使用以下命令将允许使用 su 的用户添加到 wheel 组：

sudo usermod -aG wheel username

测试配置：
使用非 wheel 组用户尝试运行 su -，应提示权限拒绝：

su -
Password:
su: Permission denied

3. 优缺点分析

优点：

• 灵活性高，可以精确控制哪些用户能够使用 su。
• 与系统认证机制深度集成，适用于所有用户会话。
• 配置简单，易于管理和维护。

缺点：

• 需要手动管理 wheel 组成员，增加管理员工作量。
• 如果 wheel 组配置不当，可能导致合法用户无法切换。

适用场景：适合需要严格控制 root 访问的服务器环境，例如企业级服务器或云主机。

四、限制 su 的手段三：修改 su 命令权限

1. 通过 chmod 限制 su 权限

一个简单但较为粗暴的方法是直接修改 /bin/su 文件的权限，使其仅限于特定用户或组执行。例如，将 su 命令的权限设置为只有 root 用户和 wheel 组可执行：

sudo chown root:wheel /bin/su
sudo chmod 4750 /bin/su

• 4750 表示：
  • 4：setuid 位，确保 su 以 root 身份运行。
  • 7：root 用户具有读、写、执行权限。
  • 5：wheel 组具有读、执行权限。
  • 0：其他用户没有任何权限。

2. 效果与验证

执行上述命令后，只有 root 和 wheel 组成员能够运行 su 命令。其他用户尝试运行时会收到 Permission denied 错误：

su -
-bash: /bin/su: Permission denied

3. 优缺点分析

优点：

• 配置简单，直接有效。
• 不依赖额外的模块或服务。

缺点：

• 过于粗暴，可能影响系统其他依赖 su 的功能。
• 需要定期检查文件权限，防止被意外修改。

适用场景：适合小型系统或临时安全加固，但不推荐用于复杂生产环境。

五、限制 su 的手段四：使用 sudo 替代 su

1. sudo 的优势

sudo 是一种更安全、更灵活的权限管理工具，允许管理员为用户分配特定的命令权限，而无需提供完整的 root 访问权限。通过禁用 su 并强制使用 sudo，可以有效降低权限提升的风险。

2. 配置 sudo 限制

1. 禁用 su 命令：
   使用上述方法（PAM 或权限修改）禁用 su 命令。
2. 配置 /etc/sudoers：
   编辑 /etc/sudoers 文件（建议使用 visudo 命令），为特定用户或组分配权限。例如：

%wheel ALL=(ALL) ALL

这表示 wheel 组成员可以通过 sudo 执行所有命令。

禁止直接切换到 root：
为了防止用户通过 sudo su - 或 sudo -i 切换到 root，可以在 /etc/sudoers 中添加以下内容：

Cmnd_Alias SHELLS = /bin/sh, /bin/bash, /usr/bin/su
%wheel ALL=(ALL) ALL, !SHELLS

这将禁止 wheel 组用户通过 sudo 执行 su 或直接进入 shell。

3. 优缺点分析

优点：

• 提供细粒度的权限控制。
• 日志记录功能便于审计。
• 避免直接使用 root 密码，降低泄露风险。

缺点：

• 配置复杂，需要仔细规划 sudoers 文件。
• 用户仍可能通过其他漏洞绕过限制。

适用场景：适合需要细粒度权限管理的生产环境，如多用户服务器。

六、其他限制手段

1. 使用 AppArmor 或 SELinux

AppArmor 和 SELinux 是 Linux 的强制访问控制（MAC）机制，可以限制 su 的执行。例如，通过 AppArmor 配置文件，可以禁止特定用户或进程访问 /bin/su。

示例：AppArmor 配置：
创建 /etc/apparmor.d/disable-su 文件：

#include <tunables/global>

/bin/su {
  # 禁止所有用户执行 su
  deny /bin/su x,
}

加载配置：

sudo apparmor_parser -r /etc/apparmor.d/disable-su

2. 限制 SSH 登录

通过配置 /etc/ssh/sshd_config，可以禁止 root 登录并限制普通用户的使用，间接减少 su 的使用需求：

PermitRootLogin no
AllowUsers adminuser

重启 SSH 服务：

sudo systemctl restart sshd

3. 使用容器化技术

在容器化环境中（如 Docker），可以通过 --security-opt=no-new-privileges 参数启用类似 NoNewPrivileges 的限制，防止容器内进程通过 su 提升权限。

七、实际案例分析

案例 1：企业服务器限制 su 访问

某企业希望限制普通用户通过 su 切换到 root，仅允许管理员组成员操作。解决方案如下：

1. 配置 /etc/pam.d/su 和 /etc/login.defs，启用 pam_wheel 和 SU_WHEEL_ONLY。
2. 将管理员用户加入 wheel 组。
3. 使用 sudo 替代 su，并通过 sudoers 文件限制命令范围。
4. 启用 SELinux，配置上下文禁止非授权用户访问 /bin/su。

经过测试，非 wheel 组用户无法使用 su，而管理员可以通过 sudo 执行特权操作，系统安全性显著提升。

案例 2：容器化环境中的 NoNewPrivileges

某 Web 应用运行在 Docker 容器中，为防止容器内进程通过 su 提升权限，管理员在 docker run 命令中添加了 --security-opt=no-new-privileges 参数，并确保容器以非 root 用户运行。这有效防止了潜在的权限提升攻击。

八、总结与最佳实践

限制 su 命令的使用是 Linux 系统安全加固的重要措施。以下是几种方法的对比与推荐：

最佳实践建议：

1. 优先使用 PAM 和 Wheel 组：结合 pam_wheel 和 /etc/login.defs，实现用户级别的 su 限制。
2. 结合 sudo：通过 sudoers 配置细粒度权限，替代 su 的使用。
3. 启用 NoNewPrivileges：对于 systemd 服务，启用 NoNewPrivileges 以限制特权提升。
4. 使用 MAC 机制：在高安全性环境中，结合 AppArmor 或 SELinux 进一步增强限制。
5. 定期审计：使用工具如 Lynis 定期检查系统配置，确保限制措施有效。

通过综合运用这些手段，可以显著提升 Linux 系统的安全性，降低未经授权的权限提升风险。

以上就是Linux限制su的几种常用方法小结的详细内容，更多关于Linux限制su的方法的资料请关注脚本之家其它相关文章！