容器镜像里的 SUID 文件为何常被漏查?

安全基线清单动辄上百条，真坐到一台跑着业务的生产机前，低峰期窗口往往只有一个小时。很多人从上到下刷一遍，刷到一半超时，最后什么也没查实。有意思的是，被漏掉最多的，往往不是那些条目复杂的项，而是 SUID 文件这种"看起来早就查过了"的东西。

原因其实挺朴素。SUID 位让程序以文件属主身份运行，属主是 root 时进程就带 root 权限。正常系统里这类文件不多，几十个，集中在系统目录，属主都是 root，典型的有 su、sudo、passwd、mount、crontab 这些。正因为"看起来很正常"，盘点时容易被一眼扫过去，觉得都是基础组件，不用细看。

问题在于，判断一个 SUID 文件该不该在，靠肉眼比对路径是不够的。最省力的方式其实是问包管理器：这个文件的权限是不是被改过。RPM 系可以用 rpm -Va，输出里第二位是 M，表示权限位相对包内记录发生了变化，这类文件优先看。更值得警惕的是另一种情况——一个 SUID 文件如果 rpm -qf 报"not owned by any package"，那就不是装出来的，是后加的。这一条几乎不会误报，命中就意味着有人动过手脚或历史遗留没清。

漏查的第二个原因是命令写得不严谨。find / 如果不加 -xdev，会爬进挂载的 NFS 或对象存储，跑几十分钟还带出一堆与主机无关的路径，很多人跑一次嫌慢，下次就干脆不跑了。加上 -xdev、限定 -type f -perm -4000，输出几十行，几分钟能跑完。SGID 则要分文件和目录两种情况看，目录上的 SGID 是新建文件继承目录属组，团队协作目录常这么设，属于合理配置，不能一刀切。

第三个原因是处置方式粗暴，导致大家不敢碰。看到可疑 SUID 就删文件，风险很大。更稳的做法是先摘位、保留文件：记下原 mode，比如 4755，然后 chmod u-s。回滚就是按记下的原值改回去。摘位后要立刻验证依赖它的功能，自己写的小工具摘位后可能直接报权限不足，那说明它确实在被业务调用，得回到确认环节。这种"可回滚"的处置方式，才让人敢在有限窗口里动手。

还有一点常被忽略：SUID 摘位容易误伤 passwd 和 sudo。验证清单里，新开一个 SSH 会话（别关现有会话），确认 su -、sudo -l 正常，普通用户能改自己密码，这几条过了，才说明没摘错。

所以 SUID 被漏查，不是因为难，而是因为它太像"正常"。真要补上，办法也简单：变更前先做可回滚快照，把关键目录的 mode、属主存下来；盘点时用包管理器对一遍，重点看权限位被改过的和没有包归属的；处置时先摘位观察，不急着删。这几步做完，一个晚上足够，结论还能复核。