☰

コンボ

tag-icon • tag-icon security apt freebsd integrity
コンボ

Linuxの背景知識が多いので、FreeBSDを見て、ほとんどの内容を読んだ。FreeBSDマニュアル、これは素晴らしいです、次の情報も提供します。セキュリティ（13章）。リストされているセキュリティ関連情報がたくさんありますが、FreeBSDソースコード（ポートおよびバイナリパッケージングシステムを含む）の整合性がどのように達成されるかを見つけるか理解することはできません。

前述のように、私はいくつかのLinuxディストリビューション、特にDebianに次のメカニズムやツールがある方法に慣れています。安全なアパート元の信頼ルートは公開鍵（「Debianアーカイブ自動署名鍵」）を介して使用されていましたが、gpgは一連のハッシュリストに署名して最終的にパッケージ内のすべてのファイルを上書きします。

FreeBSDを安全に入手する方法を扱うときにFreeBSD Subversionリポジトリを使用するオプションについて説明します。

HTTPSは、他のコンピュータがFreeBSDミラーを偽装したり（通常は「中間者」攻撃と呼ばれる）、またはエンドユーザーに不適切なコンテンツを配信しようとしないようにするための優先プロトコルです。 （源泉：https://www.freebsd.org/doc/handbook/svn.html)

TLS/SSLの有用性に完全に同意しますが、これがすべての保護機能であるかどうか疑問に思います。 「セキュアチャネル」HTTPS（一部のCAは国家の行為者として表示されます）に加えて、インポート元の整合性を確認するためにFreeBSDコミュニティによって使用される他の署名付きWOTの代替案はありますか？

だから、似たようなものがあるかどうか尋ねています。セキュリティに適したDebian?

修正する:

私は、2012年初めにいくつかの異なるLinuxディストリビューション、Arch LinuxでWOT（Web of Trust）方式でパッケージ署名を確認しました。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のような設定ファイルを追加し、/usr/local/etc/pkg/keys/JdeBP.pubXeはそれを/usr/local/etc/pkg/repos/JdeBP.conf。

このコマンドを使用して、自分だけの秘密鍵でパッケージストアに署名しますpkg repo . /elsewhere/package_signing_key。これにより、リポジトリとパッケージの署名情報が3つのファイルに生成されますmeta.txz。各アーカイブには2つのファイルがあり、1つはもう1つのファイルです。ダイジェストとパッケージサイトのアーカイブには、各パッケージアーカイブファイルのハッシュが含まれています。メタアーカイブには、他の2つの名前とpkg-ngツールの一部のバージョン情報のみが含まれています。digests.txzpackagesite.txzsignature

したがって、これはSecure APTと非常によく似ています。いくつかの違いがあります。

  • Releasepkg-ngには1つのレベルしかありませんが、実際のパッケージアーカイブのチェックサムを提供するのではなく、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 意味のソースパッケージではなく、他の人がリリースしたソースパッケージを入手してビルドする自動化された方法です。ポートは、デフォルトでfetchソースに関するいくつかのガイドラインを含むmakefileです。ここには何を得るかについてのハッシュリストがあります。

ポート自体は、Subversion（FreeBSDの場合）またはgit（TrueOSまたはFreeNASの場合）を使用してFreeBSDまたはTrueOSリポジトリから取得されます。したがって、Subversionやgitを信頼するという標準的なアイデアが適用されます。たとえば、TrueOSでgitを使用してポート（自己）を取得するときに使用される「リモート」URLは、iXsystemsセキュリティGitHubリポジトリ（TrueOS）のHTTPS URLです。手動）がそれだ。

したがって、xeが信頼するSubversionまたはgit fetchを使用してxeがポートを取得したため、システム管理者はポートを信頼します。 Xeは（現在の）信頼できるポートにリストされているハッシュと一致するため、このポートから取得したソースアーカイブを信頼します。

ノート

Debian のRelease.gzと はPackages.gz実際に HTTP 転送を圧縮する方法にすぎません。複数のオペレーティングシステムのバージョンを処理するために予想される方法の違いなど、セキュリティとは無関係のいくつかの他の問題があります。

Debian は、長年にわたって FreeBSD が動作するように進化してきており、Wiki ページで話す方法ではもう機能しません。今日、ハッシュと署名はInReleaseFreeBSDリポジトリと同じように1つのファイルにあります。これにより、リポジトリ所有者がダウンロード間でリポジトリを更新し、署名の不一致が発生した Releaseときにダウンロード後に発生する可能性がある「破れ」の問題を回避できます。Release.gpg

（Debianはもともとこれを行った理由は、長年にわたってこれらのものを段階的に開発してきたためです。それぞれは、以前のメカニズムを変更せずに構築しPackageましReleaseたRelease.gpg。のメカニズムです。

さらに：FreeBSDにはこれを行う他の方法があります。これには「指紋認識」とdigestsファイル署名（digests.txzアーカイブ内）が含まれます。

また、鍵の署名に関するセキュリティ上の考慮事項も不明です。これは、これがセキュアAPTとどのように似ているか異なるかを議論する答えと実際には関係がないためです。秘密鍵セキュリティの要件は、公開/秘密鍵を使用した署名の全体的な概念に共通であり、ストレージ構造とは無関係です。

追加読書

おすすめ記事