☰

套餐

tag-icon • tag-icon security apt freebsd integrity
套餐

由于具有更多的 Linux 背景，我研究了 FreeBSD，并且阅读了大部分内容FreeBSD 手册，这很好，也提供了很多关于安全（第 13 章）。尽管列出了许多与安全相关的信息，但我无法找到/理解 FreeBSD 源代码的完整性是如何实现的（以及端口和二进制包系统）。

如前所述，我习惯了一些 Linux 发行版的方式，更具体地说，是 Debian，其中有一种机制或工具称为安全公寓在原始信任根通过公钥（“Debian Archive 自动签名密钥”）使用时，gpg 对一系列哈希列表进行签名，最终覆盖包中的所有文件。

在处理如何安全地获取 FreeBSD 时，它提到了使用 FreeBSD subversion 存储库的选项，其中指出了

HTTPS 是首选协议，可防止另一台计算机冒充 FreeBSD 镜像（通常称为“中间人”攻击）或以其他方式尝试向最终用户发送不良内容。 （ 来源：https://www.freebsd.org/doc/handbook/svn.html）

虽然我完全同意 TLS/SSL 的有用性，但我想知道这是否是所有可用的保护？除了“安全通道”HTTPS（某些 CA 似乎是国家参与者）之外，FreeBSD 社区是否还使用某种其他签名 WOT 替代方案来检查所获取源的完整性？

因此我问的是有类似的东西吗安全-aptDebian 的？

更新：

我已经从其他一些 Linux 发行版中检查过通过信任网 (WOT) 方法进行的包签名，Arch Linux 最早是在 2012 年（参见https://pierre-schmitz.com/trust-the-master-keys/），而对于 gentoo 来说似乎也存在类似的情况，但我不知道它是什么时候引入的。 https://wiki.gentoo.org/wiki/Integrity/Concepts

无论如何，Linux 发行版似乎一直在努力解决包/源代码的完整性问题，所以我非常肯定 BSD 的安全和命令领域中存在类似的东西，对吧？

答案1

套餐

我发布了一个签名的包存储库，以下是它的工作原理。

系统管理员通过添加配置文件（例如/usr/local/etc/pkg/repos/JdeBP.conf.作为这样做的一部分，xe 告诉包管理器用于检查存储库上的签名的公钥。 Xe 以某种适当可信的方式从我这里获取此密钥，并将其保存在诸如/usr/local/etc/pkg/keys/JdeBP.pub.然后 Xe 将其命名为/usr/local/etc/pkg/repos/JdeBP.conf.

我使用命令使用只有我拥有的私钥对包存储库进行签名pkg repo . /elsewhere/package_signing_key。这将在三个文件meta.txz、digests.txz和中创建有关存储库和包的签名信息packagesite.txz。每个档案都有两个文件，一个是signature另一个的文件。摘要和包站点存档包含每个包存档文件的哈希值。元存档仅包含其他两个的名称以及 pkg-ng 工具的一些版本信息。

所以这非常类似于 Secure APT。有一些区别：

  • pkg-ng 只有一级，而 不是Release给出实际包存档的校验和Packages，然后给出哈希值。直接给出实际包档案的哈希值。Packagespackagesite.yaml
  • 文件（覆盖整个存储库）及其文件不是被拆分为单独可下载的文件Release和文件Release.gpg，而是在一次操作（和一个 HTTP/FTP 事务）中作为一个单元下载Packages为文件。Sourcespackagesite.yamlsignaturefetchpackagesite.txz

但想法大致相同。系统管理员相信该packagesite.yaml文件来自我，因为signature可以根据本地存储的可信公钥副本检查其随附文件。系统管理员相信该redo-1.3.txz文件来自我，因为它的哈希值与（现在）受信任的packagesite.yaml.

港口

港口是一个非常不同的鱼群。 Debian 的 Secure APT 将源代码包视为更多的包。 FreeBSD/TrueOS 移植不是 Debian 意义上的源包，而是获取和构建其他人发布的源包的自动化方式。端口本质上是一个 makefile，其中包含一些有关fetch来源的说明。它有一个要获取的内容的哈希列表。

端口本身来自 FreeBSD 或 TrueOS 存储库，使用 Subversion（如果是 FreeBSD）或 git（如果是 TrueOS 或 FreeNAS）。因此，信任 Subversion 或 git 的标准思想是适用的。例如，在 TrueOS 上，使用 git 获取端口（本身）时使用的“远程”URL 是 iXsystems 担保的 GitHub 存储库的 HTTPS url（在 TrueOS 中）手册) 是它所拥有的。

因此，系统管理员信任某个端口，因为 xe 已使用 xe 信任的 Subversion 或 git fetch 获取了该端口。 Xe 信任该端口获取的源存档，因为它与（现在）受信任端口中列出的哈希相匹配。

笔记

Debian 的Release.gz和Packages.gz实际上只是压缩 HTTP 传输的方法。我掩盖了一些与安全无关的其他事情，例如处理多个操作系统版本的预期方式的差异。

多年来，Debian 已经朝着 FreeBSD 的工作方式发展，并且不再像 wiki 页面所说的那样工作。如今，哈希值和签名都在一个InRelease文件中，更像是 FreeBSD 存储库。这可以防止在下载Release后存储库所有者在两次下载之间更新存储库时发生的“撕裂”问题Release.gpg，从而导致签名不匹配。

（Debian 最初只是这样做，因为多年来它分阶段发展这些东西，每个东西都建立在前面的机制之上，而没有改变它们：首先是系统Package，然后是Release之上的机制，然后Release.gpg是之上的机制。）

另外：FreeBSD 有另一种不同的方法来做到这一点，其中涉及“指纹”和签名digests文件（在digests.txz存档中）。

我还掩盖了签名密钥的安全注意事项，因为这与讨论这与安全 APT 有何相似/不同的答案并不真正相关。私钥安全性的要求对于使用公钥/私钥签名的整个概念是通用的，并且独立于存储库结构。

进一步阅读

相关内容