当前位置：首页 > backend >正文

Linux 禁止 su 的几种限制手段：从 NoNewPrivileges 到 PAM 配置

backend 2025/8/29 17:52:27

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

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

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

密码泄露风险：如果 root 密码被泄露，任何知道密码的用户都可以通过 su 切换到 root，执行任意操作。
权限提升漏洞：某些程序可能利用 su 或 setuid 机制提升权限，导致非授权用户获取特权。
误操作风险：普通用户切换到 root 后，可能因误操作导致系统配置错误或数据丢失。
安全审计难度：未受限的 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 限制

禁用 su 命令：
使用上述方法（PAM 或权限修改）禁用 su 命令。
配置 /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 {# 禁止所有用户执行 sudeny /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，仅允许管理员组成员操作。解决方案如下：

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

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

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

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

八、总结与最佳实践

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

方法	复杂度	灵活性	适用场景	推荐指数
NoNewPrivileges	低	中	systemd 服务安全加固	★★★★☆
PAM + Wheel 组	中	高	用户级权限控制	★★★★★
修改 su 权限	低	低	临时或小型系统	★★★☆☆
使用 sudo 替代	高	高	生产环境，细粒度权限管理	★★★★★
AppArmor/SELinux	高	高	高安全性需求环境	★★★★☆