应禁用高风险suid/sgid文件：属主为root且有漏洞历史的（如旧版find、mount）、非核心却设suid的可写脚本、sgid目录属组为root且开放写入、权限显示大写s的无效配置；禁用须按确认用途、限制访问、安全取消三步执行。
Linux 系统中，SUID 和 SGID 文件一旦被滥用或配置不当，可能成为提权入口。禁用危险项不是简单删掉权限，而是先识别、再评估、最后安全处置——重点在于“哪些该禁”和“怎么禁才不伤系统功能”。
哪些 SUID/SGID 文件算“危险”？
真正危险的不是所有带 s 的文件，而是满足以下任一条件的：
- 属主是 root，但程序逻辑复杂、有本地提权漏洞历史（如旧版
find、mount、sudo未打补丁版本） - 非系统核心工具却设了 SUID，比如普通用户可写的脚本被硬编码 chmod 4755（内核虽忽略脚本 SUID，但显示 s 会误导运维）
- SGID 目录属组为 root 或 wheel，且目录本身开放写入（如
/var/log下误配的 SGID 子目录） - 权限位显示大写 S 或 S（即无执行权却设了特殊位），属于配置错误，应清理而非保留
快速定位高风险项的命令
不用逐个 ls -l，用组合命令精准筛选：
- 查所有 SUID 文件：
find / -perm -4000 -type f 2>/dev/null | xargs ls -l - 查所有 SGID 文件（含目录）：
find / -perm -2000 -type f -o -type d 2>/dev/null | xargs ls -ld - 排除白名单路径（如 /usr/bin/passwd、/bin/ping）：
find / -perm -4000 -type f 2>/dev/null | grep -vE "(^/usr/bin/passwd$|^/bin/ping$|^/usr/bin/newgrp$)" - 专找“无效 SUID”（大写 S）：
find / -perm -4000 -type f ! -executable 2>/dev/null | xargs ls -l
禁用操作必须分三步走
直接 chmod u-s 可能导致服务异常，务必按顺序操作：
-
第一步：确认用途 —— 查该文件是否被系统服务或用户脚本依赖。例如
/usr/bin/at设 SUID 是为了切换 UID 提交作业，禁用后at命令将失败 -
第二步：限制访问 —— 比直接取消更稳妥：改权限为
chmod 4700（仅 root 可执行），或用 ACL 限定特定用户组：setfacl -m u:admin:r-x /path/to/binary -
第三步：安全取消 —— 确认无影响后执行：
chmod u-s /path/to/file（SUID）或chmod g-s /path/to/dir（SGID 目录）。对脚本文件，顺手删掉无效的 SUID 位，避免后续误判
特别注意 SGID 目录的“隐性风险”
SGID 目录本身不危险，但若配合宽松 umask 或用户组管理松散，会放大风险：
- 检查目录属组是否包含过多用户：
getent group sharedgroup，剔除无关账号 - 验证新建文件是否真继承属组：
umask 002; touch /shared/test; ls -l /shared/test—— 若属组不是目录所属组，说明 SGID 未生效或被 umask 抵消 - 禁用非协作目录的 SGID：
chmod 2755改为chmod 755，尤其不要在/home或用户主目录下设 SGID
