Linux系统中SUID/SGID误配是提权风险源，须仅保留必要项、清理非授权设置并限制执行范围；通过find命令筛查，结合功能、包管理器来源及替代方案评估合理性，再用chmod移除或收紧权限，并建立扫描告警与白名单常态化防护。
Linux系统中，二进制文件若被错误设置SUID/SGID（即S位），可能成为提权攻击入口。加固核心在于：只保留必要S位，清理非授权设置，并限制可执行权限范围。
识别高风险S位文件
系统默认会为少数关键程序（如passwd、sudo、ping）设置SUID，其余多数属异常配置。可通过以下命令快速筛查：
-
查找所有SUID文件：
find / -type f -perm -4000 2>/dev/null -
查找所有SGID文件：
find / -type f -perm -2000 2>/dev/null - 重点关注/usr/bin、/bin、/usr/local/bin等路径下非标准二进制
判断S位是否合理
不能仅凭存在S位就删除，需结合功能与最小权限原则评估：
- 确认该程序是否必须以root身份运行（如mount需访问设备节点）
- 检查其是否由系统包管理器安装（如dpkg -S或rpm -qf），非官方来源的SUID二进制应高度怀疑
- 验证是否有替代方案（例如用sudoers规则替代自定义SUID工具）
安全清理与权限收紧
对确认无需S位的文件，直接清除；对必须保留的，限制其可执行范围：
- 移除SUID：
chmod u-s /path/to/binary - 移除SGID：
chmod g-s /path/to/binary - 若需保留但防滥用，可配合chmod 750 + 专属组，并确保非授权用户不在该组内
- 对可疑文件，先备份再清理：
cp /path/to/binary /tmp/binary.bak && chmod u-s /path/to/binary
建立常态化防护机制
单次清理易遗漏，建议嵌入运维流程：
- 将S位扫描加入日志审计脚本，每日定时执行并告警新增项
- 在Ansible/Puppet等配置平台中定义“SUID白名单”，部署时自动校验
- 开发环境禁止编译带SUID的二进制，上线前做静态权限检查
