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 策略进一步锁定执行上下文

不复杂但容易忽略。