限制su命令能有效提升系统安全性，通过pam_wheel模块配置仅允许wheel组用户使用su，实现最小权限原则，减少攻击面，强化审计与责任制，防止未授权提权和误操作。
在Linux系统中，限制
su
命令的使用，特别是通过
pam_wheel
模块进行组控制，是一种非常直接且有效的安全加固措施。它能确保只有经过授权的用户才能切换到其他用户身份，尤其是root用户，从而大大降低未授权提权的风险。
说实话，每次提到Linux权限管理，我心里总会嘀咕几句：安全和便利性，这俩货总是像天平两端，很难找到一个完美的平衡点。但对于
su
命令的限制，我觉得这天平是明显偏向安全的，而且代价并不高。
pam_wheel
模块就是我们实现这一目标的关键。它的核心思想很简单：只有属于特定“轮子组”（wheel group）的用户，才被允许使用
su
命令。这就像给特权操作加了一道门禁，只有持有“门禁卡”的人才能进去。
具体操作起来，主要分几步：
-
编辑PAM配置： 我们需要修改
su
命令的PAM配置文件。这个文件通常位于
/etc/pam.d/su
。在编辑之前，强烈建议你备份一下原始文件，以防万一。
sudo cp /etc/pam.d/su /etc/pam.d/su.bak sudo vim /etc/pam.d/su
找到类似下面这行（或者没有这行，需要手动添加）：
#auth required pam_wheel.so use_uid
将其取消注释，或者如果你想更严格一点，可以这样配置：
auth required pam_wheel.so use_uid group=wheel
这里的
group=wheel
明确指定了只有
wheel
组的用户才能使用
su
。如果你想用一个自定义的组名，比如
sudoers
，那就把
wheel
改成
sudoers
。我个人习惯用
wheel
，因为它在很多发行版里是约定俗成的特权组。
use_uid
参数意味着
pam_wheel
会检查当前用户的UID，而不是目标用户的UID。
-
创建或确认“轮子组”： 大多数Linux发行版默认都有一个名为
wheel
的组。如果没有，你需要手动创建一个：
sudo groupadd wheel
你可以通过
cat /etc/group | grep wheel
来检查它是否存在。
-
将授权用户添加到“轮子组”： 这是最关键的一步。只有被添加到这个组的用户，才能使用
su
。
sudo usermod -aG wheel your_username
将
your_username
替换为你想要授权的用户名。
-aG
参数很重要，
-a
表示添加到附加组，
-G
指定组名，这样不会覆盖用户原有的主组。
-
保存并测试： 保存
/etc/pam.d/su
文件后，配置就会立即生效。你可以用一个不在
wheel
组的用户尝试
su -
，它应该会被拒绝。然后用一个在
wheel
组的用户尝试，它应该能成功。
这套流程走下来，你就能对
su
命令的使用权限进行精细化控制了。在我看来，这种“白名单”式的管理方式，远比“黑名单”更让人安心。
限制su命令能有效提升系统安全性吗？
当然，这几乎是一个不言自明的肯定答案。在我这么多年的系统管理经验中，限制
su
命令的使用，绝对是提升系统安全性最直接、最有效的一招。这不仅仅是技术操作，更是安全哲学的一种体现——最小权限原则。
想想看，如果任何一个普通用户都能通过
su
命令尝试切换到
root
，那意味着什么？这意味着一旦某个普通用户的密码被破解，或者用户本身被社工，攻击者就能轻易地尝试提权到
root
。这简直是给攻击者敞开了一扇大门。
限制
su
命令，特别是通过
pam_wheel
这种方式，实际上是在构建一道屏障：
- 减少攻击面： 不是所有用户都有能力或需要执行特权操作。将
su
的使用权限定在少数几个可信的管理员账户上，就大大缩小了潜在的攻击入口。即使一个普通用户账户被攻陷，攻击者也无法通过
su
直接尝试提权，因为他们不在
wheel
组里。
- 强化审计和责任制： 当只有特定用户能使用
su
时，任何通过
su
进行的特权操作都能更容易地追溯到具体的人。这在团队协作环境中尤为重要，谁做了什么，一目了然。如果每个人都能
su
到
root
，那一旦出了问题，责任很难界定。
- 防止误操作： 有时候，安全问题并非来自恶意攻击，而是源于无意的错误。一个不熟悉命令的普通用户，如果被允许
su
到
root
，一个不小心就可能执行一些破坏性的