journalctl --verify 仅在启用 Forward Secure Sealing（Seal=yes）时具备防篡改效力，需配置journald.conf、运行--setup-keys、重启服务并验证HEADER_SEALED标记后方可有效检测日志哈希链完整性。
journalctl --verify 是验证 systemd journal 日志文件是否被篡改的直接手段，但它只在启用 Forward Secure Sealing（前向安全密封）的前提下才具备实际防篡改效力。未开启 Seal 的日志，即使校验通过，也不能证明历史条目未被修改。
确保密封机制已启用
这是验证有效的前提。若未启用 Seal，--verify 仅检查基础结构完整性（如对象头、校验和），无法检测对历史日志内容的篡改。
- 编辑 /etc/systemd/journald.conf，确认以下配置存在且未被注释：
[Journal]
Storage=persistent
Seal=yes
- 首次启用后，必须运行 journalctl --setup-keys 生成初始密钥；密钥存于 /var/log/journal/<machine-id>/.journal-secrets/，权限为 600 且仅 root 可读
- 重启服务使配置生效：systemctl restart systemd-journald
- 验证日志文件头是否标记为 sealed：运行 journalctl --header | grep SEALED，应输出 HEADER_COMPATIBLE_SEALED: yes
执行完整性验证
使用 --verify 命令扫描日志文件，它会逐块验证哈希链与 TAG 标签的一致性。
- 验证全部持久化日志：journalctl --verify
- 验证特定启动的日志：journalctl -b -1 --verify
- 验证指定目录下的所有日志：journalctl -D /var/log/journal/ --verify
- 验证单个 .journal 文件：journalctl --file /var/log/journal/xxx.journal --verify
正常输出以 “PASS” 结尾；若发现哈希链断裂或 TAG 不匹配，会明确提示 “FAIL” 并指出出问题的起始偏移量和时间点。
理解验证结果的关键细节
--verify 不是“一次验证终身可信”，它的有效性依赖于持续的密封行为和密钥保护。
- 每次验证时，journalctl 会重新计算从首个 TAG 开始的所有后续哈希链；任意一处修改都会导致后续所有 TAG 验证失败
- 验证过程不修改日志，也不依赖网络或外部证书，完全离线完成
- 若系统时间被恶意回拨，可能影响 TAG 生成节奏，间接削弱密封效果；建议配合 NTP 或硬件时钟同步
- 验证通过仅说明“当前磁盘上的日志块自密封以来未被改动”，不能替代访问控制——确保 /var/log/journal/ 目录及密钥文件严格限制为 root:systemd-journal 且权限为 750/600
日常运维中的实用建议
将验证纳入审计流程，而非仅在怀疑时才运行。
- 可加入定时任务，每周执行一次并记录结果：journalctl --verify 2>&1 | tee /var/log/journal-verify-$(date +\%F).log
- 结合 --disk-usage 和 --vacuum-time=30d 管理日志生命周期，避免因空间不足触发自动清理而丢失早期 sealed 数据
- 如需长期归档，应导出为 export 或 json-pretty 格式，并对归档文件单独签名，因为 --verify 对导出文本无效
