説明
Starting with version 0.6, APT contains code that does signature checking of the Release file for all repositories. This ensures that data like packages in the archive can't be modified by people who have no access to the Release file signing key. Starting with version 1.1 APT requires repositories to provide recent authentication information for unimpeded usage of the repository.
If an archive has an unsigned Release file or no Release file at all current APT versions will refuse to download data from them by default in update operations and even if forced to download front-ends like apt-get(8) will require explicit confirmation if an installation request includes a package from such an unauthenticated archive.
As a temporary exception apt-get(8) (not apt(8)!) raises warnings only if it encounters unauthenticated archives to give a slightly longer grace period on this backward compatibility effecting change. This exception will be removed in future releases and you can opt-out of this grace period by setting the configuration option Binary::apt-get::Acquire::AllowInsecureRepositories to false or --no-allow-insecure-repositories on the command line.
You can force all APT clients to raise only warnings by setting the configuration option Acquire::AllowInsecureRepositories to true. Individual repositories can also be allowed to be insecure via the sources.list(5) option allow-insecure=yes. Note that insecure repositories are strongly discouraged and all options to force apt to continue supporting them will eventually be removed. Users also have the Trusted option available to disable even the warnings, but be sure to understand the implications as detailed in sources.list(5).
A repository which previously was authentication but would loose this state in an update operation raises an error in all APT clients irrespective of the option to allow or forbid usage of insecure repositories. The error can be overcome by additionally setting Acquire::AllowDowngradeToInsecureRepositories to true or for Individual repositories with the sources.list(5) option allow-downgrade-to-insecure=yes.
apt-get(8), aptitude(8), synaptic(8) といったパッケージフロントエンドは、この新認証機能をサポートしています。
信頼済リポジトリ
apt アーカイブからエンドユーザまでの信頼の輪は、いくつかのステップで構成されています。apt-secure は、この輪の最後のステップで、「アーカイブを信頼する」ということは、パッケージに悪意のあるコードが含まれていないことを信頼するということではなく、アーカイブメンテナを信頼するということを意味します。これは、アーカイブの完全性が保たれていることを保証するのは、アーカイブメンテナの責任だということです。
apt-secure はパッケージレベルの署名検証は行いません。そのようなツールが必要な場合は、debsig-verify や debsign (debsig-verify パッケージと devscripts パッケージでそれぞれ提供されています) を確認してください。
Debian における信頼の輪は、(例えば) 新しいパッケージやパッケージの新バージョンを、メンテナが Debian アーカイブにアップロードすることから始まります。これが有効になるには、アップロードの際に、Debian メンテナキーリング (debian-keyring パッケージに収録) にあるメンテナのキーで署名する必要があります。メンテナのキーは、キーの所有者の ID を確保するため、事前に確立した手続きの後で、他のメンテナに署名されています。同様の手順は、すべての Debian ベースのディストリビューションに存在します。
アップロードされたパッケージが検証されてアーカイブに格納されると、メンテナの署名を取り外し、パッケージのチェックサムを計算して、Packages ファイルに格納します。その後、全 Packages ファイルのチェックサムを計算して、Release ファイルに格納します。Release ファイルは、その Debian リリースのアーカイブキーで署名され、Debian ミラーサイトでパッケージや Packages ファイルとともに配布されます。このキーは、debian-archive-keyring パッケージに収録されている、Debian アーカイブキーリングに含まれます。
エンドユーザは誰でも、Release ファイルの署名をチェックし、パッケージのチェックサムを抽出して、手でダウンロードしたパッケージのチェックサムと比較できます。また、APT が自動的に行うのに任せることもできます。
以上は、パッケージごとの署名チェックとは違うことに注意してください。以下のように考えられる 2 種類の攻撃を防ぐよう設計されています。
- • ネットワーク中間者攻撃。署名をチェックしないと、悪意あるエージェントがパッケージダウンロードプロセスに割り込んだり、ネットワーク構成要素 (ルータ、スイッチなど) の制御や、悪漢サーバへのネットワークトラフィックのリダイレクトなど (ARP スプーフィング攻撃や DNS スプーフィング攻撃) で、悪意あるソフトウェアを掴まされたりします。
- • ミラーネットワーク感染。署名をチェックしないと、悪意あるエージェントがミラーホストに感染し、このホストからダウンロードしたユーザすべてに、悪意あるソフトウェアが伝播するようにファイルを変更できます。
しかしこれは、(パッケージに署名する) マスターサーバ自体の侵害や、Release ファイルに署名するのに使用したキーの漏洩を防げません。いずれにせよ、この機構はパッケージごとの署名を補完することができます。
ユーザ設定
apt-key は、リポジトリを信頼するために APT が使用するキーリストを管理するプログラムです。信頼されたキーのリストにキーを追加または削除するために使用することができます。キーが署名することができるアーカイブは、sources.list(5) 中の Signed-By を介して制限可能です。
デフォルトのインストールでは、すでにデフォルトのリポジトリからセキュアにパッケージを取得するためにすべてのキーが含まれていることに注意してください。そのため、サードパーティのリポジトリを追加している場合は apt-key で操作する必要があります。
新しいキーを追加するためには、まずキーをダウンロードする必要があります (取得する際には、信頼できる通信チャネルを使用するよう、特に留意してください)。取得したキーを、apt-key で追加し、apt-get update を実行してください。以上により、apt は設定済みのアーカイブから、InRelease ファイルや Release.gpg ファイルをダウンロード・検証できるようになります。
アーカイブ設定
あなたがメンテナンスしているアーカイブで、アーカイブ署名を提供したい場合、以下のようにしてください。
- • 既に存在しているのでなければ、最上位 Release ファイルを作成してください。apt-ftparchive release (apt-utils で提供) を実行すると、作成できます。
- • 署名します。gpg --clearsign -o InRelease Release や gpg -abs -o Release.gpg Release を実行して、署名してください。
- • キーのフィンガープリントを公開します。これにより、ユーザは、アーカイブ内のファイルを認証するためにインポートする必要があるキーを知るでしょう。これは、ディストリビューションのアップデートとキーの更新を後で自動的に行うことができる debian-archive-keyring を実行する Debian のような独自のキーリングパッケージで鍵を公開するのが最善です。
- • アーカイブとキーを追加する方法について説明します。ユーザがセキュアにキーを取得できない場合は、上述の信頼の輪が壊れています。ユーザのキー追加を助けることができる方法は、アーカイブとすでに信頼のウェブを活用するように (ディストリビューションのデフォルトのリポジトリのように) 設定している別のアーカイブユーザに含まれたあなたのキーリングパッケージを持つまでは、アーカイブと対象者に依存します。
アーカイブの内容に変化がある場合 (新しいパッケージの追加や削除)、アーカイブメンテナは前述の最初の 2 ステップに従わなければなりません。
バグ
m[blue]APT バグページm[][3] をご覧ください。 APT のバグを報告する場合は、 /usr/share/doc/debian/bug-reporting.txt や reportbug(1) コマンドをご覧ください。
著者
APT は APT チーム <[email protected]> によって書かれました。
マニュアルページ作者
このマニュアルページは Javier Fernández-Sanguino Peña, Isaac Jones, Colin Walters, Florian Weimer, Michael Vogt の作業を元にしています。
翻訳
倉澤 望 <[email protected]> (2003-2006,2009-2012), Takuma Yamada <[email protected]> (2016), Debian JP Documentation ML <[email protected]>
この翻訳文書には未訳部分が含まれている可能性があることに 注意してください。 翻訳がオリジナルに追従できていない場合、 内容を失わないようにこのようにしています。
著者
Gunthorpe Jason[FAMILY Given]
[FAMILY Given]
注記
- 1.
- Debian Security Infrastructure
- 2.
- Strong Distribution HOWTO
- 3.
-
APT バグページ