核心是先筛可疑项、再逐个验证、最后安全收紧：保留passwd、sudo等必要SUID/SGID，用sudo find / -xdev -type f -perm -4000/2000/6000 2>/dev/null精准定位，排除白名单后人工核查路径、属主、功能，按查依赖→限访问→安全取消三步处置。
直接查并收缩非必要 SUID/SGID 权限，核心不是“全删”，而是“先筛出可疑项、再逐个验证、最后安全收紧”。系统自带的 passwd、sudo、ping、newgrp 等必须保留；其余多数是误配、遗留或脚本硬设，应清理。
用 find 精准定位所有 SUID 和 SGID 文件
必须加 sudo，否则跳过大量受限路径；加 -xdev 避免卡在 /proc、/sys 或 NFS 挂载点；2>/dev/null 过滤权限报错，让结果干净可读：
- 查全部 SUID 文件：
sudo find / -xdev -type f -perm -4000 2>/dev/null - 查全部 SGID 文件：
sudo find / -xdev -type f -perm -2000 2>/dev/null - 查同时带 SUID 和 SGID 的文件（双重特权）：
sudo find / -xdev -type f -perm -6000 2>/dev/null
注意：-perm /6000 是“SUID 或 SGID 任一存在”，会漏判真正高危的双重特权项；-perm -6000 才是“两者都必须存在”，这才是你要盯紧的目标。
快速过滤掉合法项，聚焦可疑目标
别指望命令自动判断“必要与否”——得靠路径、属主、功能三要素人工筛查。优先排除以下白名单路径和程序：
- 常见合法路径：
/usr/bin/passwd、/bin/ping、/usr/bin/sudo、/usr/bin/newgrp、/usr/bin/chsh（但后者在无交互服务器上往往冗余） - 属主非
root的 SUID 文件极大概率非法（如普通用户自己chmod u+s的脚本） - 路径非常规：出现在
/tmp、/var/tmp、/opt/xxx/bin、/home/xxx/bin下的 SUID 文件，基本可标为高危 - 权限显示大写
S（如-rwSr--r--）说明属主无执行权，SUID 无效，纯属配置错误，应直接清理
实用过滤命令示例（排除已知合法项）：sudo find /usr/bin -type f -perm -4000 2>/dev/null | grep -vE "(^/usr/bin/passwd$|^/usr/bin/sudo$|^/bin/ping$)"
确认用途后再操作：三步处置法不能跳
直接 chmod u-s 可能导致服务中断（比如 /usr/bin/at 被禁用后定时任务失败）。务必按顺序走：
-
第一步：查归属与依赖 —— 用
dpkg -S /path/to/file（Debian/Ubuntu）或rpm -qf /path/to/file（RHEL/CentOS）确认是否来自官方包；再搜 cron、systemd unit、运维脚本里是否调用了它 -
第二步：限制访问比直接取消更稳妥 —— 若不确定能否删，先收紧：改权限为
4700（仅 root 可执行），或用 ACL 限定组：setfacl -m u:admin:r-x /path/to/binary -
第三步：安全取消 —— 确认无任何依赖后，执行
chmod u-s /path/to/binary（SUID）或chmod g-s /path/to/dir（SGID 目录）；对脚本文件，顺手去掉无效 SUID 位（内核不认脚本的 SUID，但留着会误导后续审计）
操作前务必备份：cp /path/to/binary /tmp/binary.bak，尤其涉及 /usr/bin 下的系统二进制。
特别警惕 SGID 目录的隐性风险
SGID 目录本身不危险，但若配合宽松 umask 或组成员泛滥，就会放大继承风险：
- 检查目录属组是否包含无关用户：
getent group sharedgroup，剔除账号 - 验证新建文件是否真继承属组：
umask 002; touch /shared/test; ls -l /shared/test—— 若属组没继承，说明 SGID 没生效或被 umask 覆盖 - SGID 目录若属组为
root且开放写入（如误配的/var/log/subdir），应立即收紧权限或移除 SGID
最易被忽略的是：非标准路径下的 Python/shell 脚本被硬设 SUID —— 内核直接忽略，但权限位仍显示 s，既无用又制造假象，必须清掉。
