Sudo 本身没有 Digest 摘要功能，它不生成、不校验 HTTP Digest 认证相关哈希；保障脚本完整性需通过 SHA256 自校验、绝对路径调用、sudoers 精确路径限制及审计防护实现。
Sudo 本身没有 Digest 摘要功能。你提到的“Sudo 的 Digest 摘要功能”是一个常见误解，源于混淆了两个完全独立的技术概念：
- Sudo：Linux 权限委托工具，用于控制谁能在什么条件下以何种身份运行哪些命令；
- Digest（摘要）认证：HTTP 协议中的一种身份验证机制（如 RFC 7616），依赖 SHA-256/MD5 等哈希算法生成一次性响应令牌，与 sudo 的权限执行逻辑无任何实现关联。
所以，sudo 不生成、不校验、也不理解 HTTP Digest 质询或 HA1/HA2 哈希值。它不会主动对脚本做摘要校验，也不会把 WWW-Authenticate: Digest 这类头信息纳入权限决策。
但你的核心诉求——“保障授权脚本未被恶意篡改”——是完全合理且可落地的。真正起作用的是人工在脚本内嵌入的完整性校验逻辑，而非 sudo 自带的“Digest 功能”。
下面直击重点，告诉你怎么做：
一、用 SHA256 校验脚本自身完整性
这是防篡改最直接有效的一环。关键不在“sudo 是否支持”，而在“脚本启动时是否自我核验”。
- 预先计算脚本哈希：
sha256sum /opt/bin/backup.sh > /etc/backup.sh.sha256，并设该文件权限为644（仅 root 可写） - 在脚本第一行加入校验逻辑：
[[ "$(sha256sum "$0" | cut -d' ' -f1)" == "$(cat /etc/backup.sh.sha256 2>/dev/null)" ]] || { echo "FATAL: script integrity check failed"; exit 1; } - 确保脚本属主为 root、权限为 755，普通用户不可写：
sudo chown root:root /opt/bin/backup.sh && sudo chmod 755 /opt/bin/backup.sh
二、校验所调用外部命令的真实路径
攻击者可能替换 /usr/bin/rsync 或污染 PATH，让脚本误调恶意同名程序。
- 禁用模糊调用：不用
rsync，改用绝对路径/usr/bin/rsync - 或统一定义变量：
RSYNC=/usr/bin/rsync，后续全用$RSYNC - 运行前显式验证：
command -v rsync | grep -q '^/usr/bin/rsync$' || exit 1 - 重置 PATH 到最小安全集：
PATH="/usr/local/bin:/usr/bin:/bin"
三、sudoers 中严格限定执行范围
这才是 sudo 发挥作用的核心位置——不是靠“Digest”，而是靠“精确路径 + 无 shell 解析”。
- 用
visudo添加这一行（替换为你的真实路径）：alice ALL=(root) NOPASSWD: /opt/bin/backup.sh - 严禁通配符：
❌ /opt/bin/*.sh、❌ /opt/bin/backup*、❌ !/bin/bash - 不启用
SETENV除非必要；若启用，脚本内须校验关键变量如LANG=C、IFS=
四、配套审计与防护增强
单靠校验不够，需形成闭环。
- 确认日志已记录：检查
/var/log/auth.log或/var/log/secure中是否有完整命令路径、用户、时间戳 - 定期扫描脚本哈希是否变化（可用 cron + diff）
- 配合文件系统只读挂载（如
/opt/bin）、SELinux/AppArmor 策略进一步锁定执行上下文
不复杂但容易忽略。
