☰

验证包

tag-icon • tag-icon debian security package-management
验证包

有哪些安全系统和流程可以防止恶意第三方攻击/损害 Debian 镜像中代码的安全性，或者验证我们获得的软件包实际上是维护人员认为的软件包？

答案1

验证包

镜像的内容直接或间接使用 PGP 密钥进行签名。从 Debian 发行版的“根”开始：

  • Release，用独立签名签署Release.gpg，包含所有包索引和安装程序哈希值的哈希值（MD5、SHA1、SHA256）（InRelease现在将两者结合起来）；
  • 包索引（例如,binary-amd64）包含包的哈希值（MD5 和 SHA256）。

哈希值和签名通过工具进行检查，例如apt-get使用系统上存储的 PGP 密钥（由 管理apt-key）。因此，只要接收系统是健全的，默认情况下，如果没有通过存档 PGP 密钥（间接）签名，则无法从 Debian 存档安装任何软件包。如果镜像上的任何入侵者没有控制相关的 PGP 密钥，他们将无法替换二进制文件。

控制镜子

这意味着损害存档并不足以真正损害最终用户系统；您还需要泄露这些系统已经信任的 PGP 密钥。 （由此推论，向 Debian 系统添加密钥并不是一件可以掉以轻心的事情。）这在某种程度上解决了您的第一个问题，因为存档的安全性并不那么重要。然而，关键系统（签名发生的地方）受到严格监控和监督，很少有人可以访问它们。

维护者的期望

确保软件包“实际上是维护者认为的软件包”需要更多的参与。这是包所采用的路径：

  • 该软件包由维护者准备，并使用 Debian 密钥环中的密钥进行签名（IE属于上传的 Debian 开发人员或 Debian 维护者的密钥，上传到 Debian 密钥环服务器并由密钥环维护团队合并）；
  • 签名的包被上传到存档，并在其中进行验证（除其他事项外，使用的密钥必须位于当前密钥环中并且不得已过期，签名必须有效，并且如果包是由 DM 签名的，则DM必须有该包的相关权限）；
  • 所有上传的二进制文件都会按原样推送到最终存档（我在这里进行了一些简化，但这就是效果）；
  • 任何丢失的二进制文件都是由建造并由构建的 PGP 密钥签名，并推送到最终存档（它知道哪些构建密钥有效，并根据这些密钥验证文件）；
  • 所有这些更新最终都会被推送到镜像网络，并带有适当的索引更新（如上所述进行签名）。

如果维护者将二进制文件与包源一起上传，那么这些就是最终提供服务的文件（暂时）。由于上传二进制文件现在是可选的，因此跳过它们越来越常见，最终上传的二进制文件将被删除。 （Ubuntu 中一直都是这种情况。）其他二进制文件是否符合维护者的期望取决于构建的网络；因此，建筑物也是关键系统，受到密切监督且很少有人进入。由于所有工件都经过签名，因此始终可以验证文件的完整性：首先根据维护者的密钥，然后根据构建的密钥，最后根据存档的密钥。

原始签名在镜像上不可用，任何 DD 都可以上传丢失的二进制文件。然而，从 Debian 11 开始，档案中的所有新二进制文件都来自构建守护进程； DD 上传的二进制文件只能从不稳定的、实验性的或向后移植的存储库中获得。原始签名可以从debian-devel-更改档案。

总之，虽然当前的系统并不完美，但它确实为您可以从镜像下载的所有文件提供了可追溯性。有许多努力可以改善这种情况：可重复的构建（这将允许独立验证二进制文件与已发布源的对应关系），删除维护者提供的二进制文件......

相关内容