ArchWiki - 利用者の投稿記録 [ja]

システムメンテナンス

2025-08-17T12:44:11Z

KrisWalton: /* 壊れた更新を元に戻す */ relevantの誤訳

[[Category:システム管理]]
[[en:System maintenance]]
[[es:System maintenance]]
[[fa:نگهداشت سیستم]]
[[fr:System maintenance]]
[[pt:System maintenance]]
[[ru:System maintenance]]
[[zh-hans:System maintenance]]
{{Related articles start}}
{{Related|一般的な推奨事項}}
{{Related articles end}}
長期にわたって Arch を適切に機能させるには定期的なシステムメンテナンスが不可欠です。暇があるときにメンテナンスするのは多くのユーザーの習慣となっています。

== エラーの確認 ==

=== systemd サービスの失敗 ===

systemd サービスが failed 状態になってないか確認:

$ systemctl --failed

詳しくは [[systemd#ユニットを使う]] を参照。

=== ログファイル ===

{{ic|/var/log/}} にあるログファイルのエラーを確認し、systemd ジャーナルに記録されたメッセージも確認してください:

# journalctl -b

詳しくは [[systemd/ジャーナル]] を見て下さい。

[[Xorg]] のエラーについては [[Xorg#トラブルシューティング]]を見てください。

== バックアップ ==

重要なデータのバックアップを定期的に作成します。ケースにより適した多くの代替アプリケーションについては、[https://wiki.archlinux.jp/index.php/%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0 同期およびバックアッププログラム] を参照してください。その他の興味深い記事については [[:カテゴリ:システムリカバリ]] を参照してください。

バックアップは [[systemd/タイマー]] で自動化できます。

=== 設定ファイル ===

設定ファイルを編集する前に、問題が発生した場合に作業バージョンに戻すことができるようにバックアップを作成してください。 [[vim]] や [[emacs]] のようなエディターはこれを自動的に行うことができ、 [[etckeeper]] のようなツールは {{ic|/etc}} を [[バージョン管理システム]] (VCS) に保持します。 :詳細については、 [https://wiki.archlinux.jp/index.php/%E3%83%89%E3%83%83%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB gitignore を使う] を参照してください。

=== インストールされているパッケージのリスト ===

インストールされているすべてのパッケージのリストを維持して、完全な再インストールが避けられない場合に、元の環境を簡単に再作成できるようにします。

詳しくは [https://wiki.archlinux.jp/index.php/Pacman_%E3%83%92%E3%83%B3%E3%83%88#.E3.83.AA.E3.82.B9.E3.83.88.E3.81.8B.E3.82.89.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E3.82.92.E3.82.A4.E3.83.B3.E3.82.B9.E3.83.88.E3.83.BC.E3.83.AB.E3.81.99.E3.82.8B リストからパッケージをインストールする] をご覧ください。

=== Pacman データベース ===

[https://wiki.archlinux.jp/index.php/Pacman_%E3%83%92%E3%83%B3%E3%83%88#pacman_.E3.83.87.E3.83.BC.E3.82.BF.E3.83.99.E3.83.BC.E3.82.B9.E3.82.92.E3.83.90.E3.83.83.E3.82.AF.E3.82.A2.E3.83.83.E3.83.97 pacman データベースをバックアップ] を参照してください。

=== 暗号化メタデータ ===

[https://wiki.archlinux.org/index.php/Data-at-rest_encryption#Backup_for_disk_encryption_scenarios Backup for disk encryption scenarios] を参照してください。

===システムおよびユーザーデータ===

[https://wiki.archlinux.jp/index.php/Rsync_%E3%81%AB%E3%82%88%E3%82%8B%E3%83%95%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97 システムバックアップ] を参照してください。

== システムのアップグレード ==

[https://wiki.archlinux.jp/index.php/Pacman#.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E3.81.AE.E3.82.A2.E3.83.83.E3.83.97.E3.82.B0.E3.83.AC.E3.83.BC.E3.83.89 パッケージのアップグレード] を介して定期的にシステム全体のアップグレードを実行し、最新のバグ修正とセキュリティ更新の両方を楽しんだり、一度に手動で介入する必要のあるパッケージのアップグレードが多すぎたりしないようにすることをお勧めします。コミュニティにサポートを要求する場合、通常、システムは最新であると見なされます。

更新後に問題が発生した場合にシステムを簡単に救出できるように、Archインストールメディアまたは別の Linux ''ライブ'' CD/USB を用意してください。 Arch を実稼働環境で実行している場合、または何らかの理由でダウンタイムを許容できない場合は、最初に、重要ではない複製システムで設定ファイルの変更とソフトウェアパッケージの更新をテストします。その後、問題が発生しない場合は、本番システムに変更をロールアウトします。

システムに [[AUR]] のパッケージがある場合は、それらすべてを慎重にアップグレードしてください。

''pacman'' は強力なパッケージ管理ツールですが、すべてのケースを処理しようとするわけではありません。ユーザーは用心深く、自分のシステムを維持する責任を負わなければなりません。

=== システムをアップグレードする前に読んでください ===

アップグレードする前に、ユーザーは [https://www.archlinux.org/ Arch Linuxホームページ] にアクセスして最新ニュースを確認するか、[https://www.archlinux.org/feeds/news RSS フィード] を購読する必要があります、または [https://mailman.archlinux.org/mailman/listinfo/arch-announce/arch-announce メーリングリスト] 更新に通常とは異なるユーザーの介入が必要な場合 (''pacman'' の指示に従うだけで処理できる以上の) 適切なニュース投稿が行われます。

基本的なソフトウェア ([[カーネル]]、 [[xorg]]、 [[systemd]]、 {{Pkg|glibc}} など) を新しいバージョンにアップグレードする前に、適切な [https://bbs.archlinux.org フォーラム] で、問題が報告されているかどうかを確認します。

ユーザーは、パッケージをアップグレードすると、即時の介入が必要になる可能性のある ''予期しない'' 問題が発生する可能性があることにも同様に注意する必要があります。したがって、重要なタスクを実行するために必要になる直前に、安定したシステムをアップグレードすることはお勧めしません。アップグレード後の問題に対処できるように、代わりに十分な時間をとって待つことをお勧めします。

{{Tip|{{aur|informant}} のような pacman フックを使用すると、前回の更新の実行以降に読んでいない新しい ArchNews がある場合に更新できなくなります。}}

=== 特定の pacman コマンドを避けてください ===

[[#部分的なアップグレードはサポートされていません|部分的なアップグレード]] は避けてください。つまり、 {{ic|pacman -Sy}} を実行しないでください。代わりに、常に {{ic|pacman -Syu}} を使用してください。

通常、pacman で {{ic|--overwrite}} オプションを使用することは避けてください。 {{ic|--overwrite}} オプションは、 glob を含む引数を取ります。 pacman を使用すると、globに一致するファイルのファイル競合チェックがバイパスされます。適切に保守されたシステムでは、Arch 開発者によって明示的に推奨された場合にのみ使用する必要があります。 [https://wiki.archlinux.jp/index.php?title=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%A1%E3%83%B3%E3%83%86%E3%83%8A%E3%83%B3%E3%82%B9&action=submit#.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.E3.82.92.E3.82.A2.E3.83.83.E3.83.97.E3.82.B0.E3.83.AC.E3.83.BC.E3.83.89.E3.81.99.E3.82.8B.E5.89.8D.E3.81.AB.E8.AA.AD.E3.82.93.E3.81.A7.E3.81.8F.E3.81.A0.E3.81.95.E3.81.84 システムをアップグレードする前に読んでください] セクションを参照してください。

pacman で {{ic|-d}} オプションを使用することは避けてください。 {{ic|pacman -Rdd ''package''}} は、パッケージの削除中に依存関係のチェックをスキップします。その結果、重大な依存関係を提供するパッケージが削除され、システムが破損する可能性があります。

=== 部分的なアップグレードはサポートされていません ===

Arch Linux は[[Wikipedia:ローリングリリース|ローリングリリース]]のディストリビューションです。つまり、新しい[[Wikipedia:ja:ライブラリ|ライブラリ]]のバージョンがリポジトリにプッシュされると、[https://archlinux.org/people/developers/ 開発者]や[[Package Maintainers|パッケージメンテナー]]が、それらのライブラリに対して再ビルドが必要なすべてのパッケージをリポジトリ内で再構築します。
例えば、2つのパッケージが同じライブラリに依存している場合、一方のパッケージをアップグレードすると、その依存関係としてライブラリもアップグレードされる可能性があります。その結果、古いバージョンのライブラリに依存しているもう一方のパッケージが動作しなくなることがあります。

そのため、部分的なアップグレードは'''サポートされていません''' '''絶対に'''使用しないでください:

* {{ic|pacman -Sy ''package''}}
* {{ic|pacman -Sy}} の後に {{ic|pacman -S ''package''}} を実行する方法 (パッケージのインストール時に {{ic|-S'''u'''}} がない点に注意)
* {{ic|pacman -Syuw}} ({{ic|pacman -Syuw}} も {{ic|pacman -Sy}} と同様のリスクを伴い、''pacman'' の同期データベースを更新するものの、新しいパッケージをインストールしないため注意が必要)

パッケージデータベースを更新する際は、'''必ず''' {{ic|pacman -Syu}} を使用して完全なアップグレードを行ってください。
なお、{{ic|pacman -Syu}} がエラーによってアップグレードを実行できなかった場合、その結果は {{ic|pacman -Sy}} を実行したのと同じになります。したがって、エラーを解決し、できるだけ早くアップグレードを完了させる必要があります。

同じ理由で、{{ic|IgnorePkg}} や {{ic|IgnoreGroup}} を使用する際も十分注意してください。
システムにローカルでビルドされたパッケージ(例えば [[AUR]] パッケージ)がある場合、それらの依存関係が[[Wikipedia:soname|soname]]の変更(バンプ)を受けた際には、ユーザーが再ビルドする必要があります。

もし部分的なアップグレードが行われ、バイナリがリンク先のライブラリを見つけられずに壊れてしまった場合、'''シンボリックリンクを作成して "修正" しようとしてはいけません'''。
ライブラリが [[Wikipedia:soname|soname]] の変更を受けるのは、'''後方互換性がない場合'''です。
適切に同期されたミラーに対してシンプルに {{ic|pacman -Syu}} を実行すれば、''pacman'' 自体が壊れていない限り問題は解決します。

また、{{Pkg|pacman-contrib}} パッケージに含まれる bash スクリプト ''checkupdates'' を使用すると、システム全体の更新を行わずにインストール済みパッケージのアップグレードを安全に確認できます。さらに、同期データベースを変更せずに、保留中のアップデートを pacman のキャッシュにダウンロードするオプションも提供されています。

=== アップグレード中のアラートに対応 ===

システムをアップグレードするときは、[[pacman]]が提供するアラート通知に注意してください。ユーザーが追加のアクションを必要とする場合は、すぐに対処してください。パックマンアラートがわかりにくい場合は、フォーラムと最近のニュース投稿で詳細な手順を検索してください。

=== 新しい設定ファイルを迅速に処理する ===

pacman を呼び出すと、 {{ic|.pacnew}} ファイルと {{ic|.pacsave}} ファイルを作成できます。パックマンはこれが発生したときに通知を提供し、ユーザーはこれらのファイルを迅速に処理する必要があります。詳細な手順については、 [https://wiki.archlinux.jp/index.php/Pacnew_%E3%81%A8_Pacsave_%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB Pacnew と Pacsave ファイル] wiki ページを参照してください。

また、コピーまたは作成した可能性のある他の設定ファイルについても検討してください。パッケージにホームディレクトリにコピーした設定例がある場合は、新しいパッケージが作成されているかどうかを確認してください。

=== アップグレード後に再起動 ===

通常、アップグレードは既存のプロセスには適用されません。アップグレードを完全に適用するには、プロセスを再起動する必要があります。

{{Pkg|archlinux-contrib}} パッケージには [https://github.com/archlinux/contrib/blob/master/admin/checkservices checkservices] というスクリプトが含まれています。このスクリプトは [[Pacnew と Pacsave ファイル#pacdiff|pacdiff]] を実行して ''.pacnew'' ファイルをマージし、その後、更新前のライブラリで動作しているプロセスの存在をチェックして、そのプロセスを再起動するかをユーザに確認します。

カーネルは、再起動せずにパッチを適用するのが特に困難です。再起動は常に最も安全なオプションですが、これが非常に不便な場合は、 [[カーネルライブパッチ]] を使用して再起動せずにアップグレードを適用できます。

=== 壊れた更新を元に戻す ===

パッケージの更新によって問題が発生することが予想される/わかっている場合、パッケージャーは、パッケージが更新されたときに pacman が適切なメッセージを表示するようにします。更新後に問題が発生した場合は、 {{ic|/var/log/pacman.log}} を参照して、 pacman の出力を再確認してください。

{{Tip|{{AUR|wat-git}} などのログビューアを使用して pacman ログを検索できます。}}

この時点で、pacmanを通じて入手できる情報がないこと、https://www.archlinux.org/ に関連するニュースがないこと、および更新に関するフォーラムの投稿がないことを確認した後で、問題の [[パッケージのダウングレード]] して [https://bbs.archlinux.org フォーラム]、 [[IRC]] で支援を求めることを検討してください。

=== 孤立したパッケージとドロップされたパッケージを確認します ===

アップグレード後、不要になったパッケージや、公式リポジトリから削除されたパッケージが存在する可能性があります。

{{ic|pacman -Qtd}} を使用すると、依存関係としてインストールされたものの、現在は他のパッケージから依存されていないパッケージを確認できます。
もし孤立した (orphan) パッケージがまだ必要な場合は、[[インストール理由]]を明示的 (explicit) に変更することを推奨します。
一方で、不要になった場合は削除できます。詳細は [[pacman/ヒントとテクニック#使用していないパッケージ (孤立したパッケージ) の削除]] を参照してください。

さらに、一部のパッケージはリモートリポジトリには存在しなくなったものの、ローカルシステムには残っている場合があります。
すべての外部(foreign)パッケージを一覧表示するには、{{ic|pacman -Qm}} を使用します。
ただし、このリストには手動でインストールしたパッケージ (例: [[AUR]] からインストールしたもの) も含まれます。
AUR で現在も利用可能なパッケージを除外するには、[https://bbs.archlinux.org/viewtopic.php?id=288205#p2116629 BBS#288205] のスクリプトを使用するか、{{AUR|ancient-packages}} ツールを試してみてください。

== パッケージマネージャーを使用してソフトウェアをインストールする ==

[[Pacman]] は、ファイルを追跡する上であなたよりもはるかに優れた仕事をします。手動でインストールすると、遅かれ早かれ、何をしたかを忘れたり、インストールした場所を忘れたり、競合するソフトウェアをインストールしたり、間違った場所にインストールしたりします。

* [https://wiki.archlinux.jp/index.php/Pacman#.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E3.81.AE.E3.82.A4.E3.83.B3.E3.82.B9.E3.83.88.E3.83.BC.E3.83.AB パッケージのインストール] セクションの方法を使用して公式リポジトリからパッケージをインストールします。
* ご希望のプログラムがない場合は、 [[AUR]] で誰かがパッケージを作成していないか確認してください。その記事の方法に従ってインストールしてください。
* 最後に、必要なプログラムが公式リポジトリまたは AUR にない場合は、そのプログラムの[[パッケージの作成]]方法を学習してください。

不適切にインストールされたファイルをクリーンアップするには、[[pacman/ヒントとテクニック#どのパッケージにも所有されていないファイルを特定する]] を参照してください。

=== オープンソースドライバーを選択してください ===

プロプライエタリドライバに頼る前に、常にオープンソースドライバを試してください。ほとんどの場合、オープンソースドライバーはプロプライエタリドライバーよりも安定していて信頼性があります。オープンソースドライバーのバグは、より簡単かつ迅速に修正されます。プロプライエタリドライバーはより多くの機能を提供できますが、これには安定性が犠牲になる可能性があります。このジレンマを回避するには、完全な機能を備えた成熟したオープンソースドライバーをサポートしていることがわかっているハードウェアコンポーネントを選択してみてください。オープンソースのLinuxドライバーを備えたハードウェアに関する情報は、 [http://www.linux-drivers.org/ linux-drivers.org] で入手できます。

=== 非公式パッケージに注意してください ===

[[AUR]] または [[非公式ユーザーリポジトリ]] のパッケージを使用する場合は注意が必要です。ほとんどは通常のユーザーによって提供されているため、公式リポジトリの標準と同じ基準ではない場合があります。 AUR パッケージのインストールを自動化する [[AUR ヘルパー]] は避けてください。 '''常に'''パッケージをビルドおよび/またはインストールする前に、 PKGBUILD の正常性、間違いまたは悪意のあるコードの兆候を確認してください。

メンテナンスを簡素化するために、使用する非公式パッケージの量を制限してください。実際に使用されているものを定期的にチェックし、他のものを削除(または公式の対応物と交換)します。便利なコマンドについては、 [https://wiki.archlinux.jp/index.php/Pacman_%E3%83%92%E3%83%B3%E3%83%88#.E3.83.A1.E3.83.B3.E3.83.86.E3.83.8A.E3.83.B3.E3.82.B9 Pacman メンテナンス] を参照してください。

=== ミラーリストを更新します ===

ミラーの品質は時間の経過とともに変化する可能性があり、一部がオフラインになったり、ダウンロード速度が低下したりする可能性があるため、pacmanのミラーリストを更新してください。

詳細については、 [[ミラー]] を参照してください。

== ファイルシステムの掃除 ==

削除するファイルを探すときは、一番ディスク容量を取っているファイルを見つけるのが重要です。この作業に役立つプログラムは以下に載っています:

* [[アプリケーション一覧#ディスク使用量表示プログラム]]。
* [[アプリケーション一覧#ディスクの消去]]。

=== パッケージキャッシュ ===

{{ic|/var/cache/pacman/pkg/}} から不要な {{ic|.pkg}} ファイルを削除して、ディスク領域を解放します。

詳細については、 [https://wiki.archlinux.jp/index.php/Pacman#.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E3.82.AD.E3.83.A3.E3.83.83.E3.82.B7.E3.83.A5.E3.81.AE.E5.89.8A.E9.99.A4 パッケージキャッシュの削除] を参照してください。

=== (孤立) した未使用のパッケージ ===

システムから未使用のパッケージを削除して、ディスクスペースを解放し、メンテナンスを簡素化します。

詳細については、 [https://wiki.archlinux.jp/index.php/Pacman_%E3%83%92%E3%83%B3%E3%83%88#.E4.BD.BF.E7.94.A8.E3.81.97.E3.81.A6.E3.81.84.E3.81.AA.E3.81.84.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E3.81.AE.E5.89.8A.E9.99.A4_.28.E5.AD.A4.E7.AB.8B.E3.81.97.E3.81.9F.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.29 使用していないパッケージの削除 (孤立したパッケージ)] を参照してください。

=== ホームディレクトリの掃除 ===

古い設定ファイルは、新しいソフトウェアのバージョンと競合したり、時間の経過とともに破損する可能性があります。
不要な設定ファイルは定期的に削除しましょう。特に、ホームディレクトリや {{ic|~/.config}} 内の設定ファイルを整理することを推奨します。
同様の理由から、異なるインストール環境間でホームディレクトリを共有する際も注意が必要です。

以下のディレクトリを確認してください:

* {{ic|~/.config/}} -- アプリケーションが設定を保存するフォルダ
* {{ic|~/.cache/}} -- プログラムのキャッシュによって巨大化することがあります
* {{ic|~/.local/share/}} -- 古いファイルがここに保存されていることがあります

詳細については、[[XDG Base Directory]] を参照してください。

ホームディレクトリに不要な一時ファイルが誤った場所に作成されるのを防ぐために、不要なファイルのリストを管理し、定期的に削除することをおすすめします。
例えば、[https://github.com/lahwaacz/Scripts/blob/master/rmshit.py rmshit.py] を使用すると便利です。

{{Aur|rmlint-git}} を使用すると、重複ファイル、空のファイル、再帰的な空ディレクトリ、壊れたシンボリックリンクを検出し、必要に応じて削除できます。

=== 壊れたシンボリックリンク ===

古い、壊れたシンボリックリンクがシステムの周りにある可能性があります。それらを削除する必要があります。これらを参照して下さい、 [https://unix.stackexchange.com/questions/34248/how-can-i-find-broken-symlinks こちら] および [http://www.commandlinefu.com/commands/view/8260/find-broken-symlinks こちら] しかし、壊れたシンボリックリンクの中には目的を果たすものもあるのでやみくもに削除しないでください [https://unix.stackexchange.com/questions/151763/is-there-a-downside-to-deleting-all-of-the-broken-symbolic-links-in-a-system]

システムの壊れたシンボリックリンクをすべてすばやく一覧表示するには、次を使用します。

# find / -type d $ -path "/dev" -o -path "/proc" -o -path "/run" -o -path "/sys" $ -prune -o -xtype l -print

次に、このリストから不要なエントリを調べて削除します。

== ヒントとテクニック ==

以下のヒントは通常は必要ありませんが、特定のユーザーはそれらが役立つと感じるかもしれません。

=== 実績のあるソフトウェアパッケージを使用する ===

Arch のローリングリリースは、最新の機能を試し、できるだけ早くアップストリームの更新を取得したいユーザーにとっては朗報ですが、システムのメンテナンスをより困難にする可能性もあります。メンテナンスを簡素化し、安定性を向上させるには、最先端のソフトウェアを避け、成熟した実績のあるソフトウェアのみをインストールするようにしてください。このようなパッケージは、主要な構成の変更や機能の削除など、難しいアップグレードを受け取る可能性が低くなります。問題が発生した場合のサポートを簡素化するために、強力で活発な開発コミュニティと多数の有能なユーザーがいるソフトウェアを優先します。

テストからの個々のパッケージであっても、テストリポジトリの使用は避けてください。これらのパッケージは実験的なものであり、安定したシステムには適していません。同様に、アップストリームの開発ソースから直接ビルドされたパッケージは避けてください。これらは通常 [[AUR]] にあり、''dev''、''devel''、''svn''、''cvs''、''git'' などの名前が付いています。

=== linux-lts パッケージをインストールします===

{{Pkg|linux-lts}} パッケージは代替の Arch カーネルパッケージであり、 [[core]] リポジトリで入手できます。この特定のカーネルバージョンには、セキュリティ修正や一部の機能バックポートなど、アップストリームからの長期サポート (LTS) があります。頻度の低いカーネル更新と安定性が必要な場合、または新しいカーネルバージョンで問題が発生した場合に備えて、フォールバックカーネルが必要な場合に役立ちます。

ブートオプションとして使用できるようにするには、 [https://wiki.archlinux.jp/index.php/Arch_%E3%83%96%E3%83%BC%E3%83%88%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9 ブートローダ] の設定ファイルを更新して LTS カーネルと RAM ディスクを使用する必要があります: {{ic|vmlinuz-linux-lts}} と {{ic|initramfs -linux-lts.img}}

== 参照 ==
* [https://bbs.archlinux.org/viewtopic.php?id=146850 Arch News Bash Script]
* [[fwupd]]

Logwatch

2025-08-07T14:28:00Z

KrisWalton: rm systemdサポート:既にサポート済みであるため

[[Category:ロギング]]
[[en:Logwatch]]
[http://www.logwatch.org/ Logwatch] は強力かつ多目的なログパーサー・アナライザーです。Logwatch はサーバーのあらゆる活動の統一的なレポートを作成して、コマンドラインやメールで閲覧することができます。

==インストール==
Logwatch は pacman で community リポジトリからインストールできます:
# pacman -S logwatch

logwatch バイナリとスクリプト、設定ファイルに加えて、pacman のパッケージには cron ジョブも含まれており、{{ic|/etc/cron.daily/0logwatch}} にインストールされます。logwatch スクリプトは perl を使用するので、perl は logwatch パッケージの依存パッケージです。

==設定==
Logwatch の設定は分散されています。複数の場所に設定を指定することができ、下の方のファイルの設定が優先されます:
* /usr/share/logwatch/default.conf/*
* /etc/logwatch/conf/dist.conf/*
* /etc/logwatch/conf/*
* スクリプトやコマンドラインの引数
Logwatch が実行されると上記の全てのファイルが読み込まれます。

上記のディレクトリの中で、設定には複数の領域があります。{{ic|logwatch.conf}} ファイルは最も高水準の設定を記述するところで、レポートの送信先やフォーマットなどを設定することができます{{ic|/usr/share/logwatch/default.conf/logwatch.conf}} の設定ファイルには全てのデフォルト設定とコメントが含まれています。デフォルト設定はそのままにして、{{ic|/etc/logwatch/conf/logwatch.conf}} で設定変数を再定義することを推奨します。

{{ic|logfiles/}} ディレクトリの中にある設定ファイルは特定のログファイルを指定しています。デフォルトで、Linux システムで一般的に使われているログファイルは既に対応しています。ログファイルの設定がない特殊なアプリケーションを使っている場合は、{{ic|default.conf/logfiles/}} ディレクトリから既存の設定をコピーして、そのアプリケーション用にカスタマイズしてください。

{{ic|services/}} フォルダには同じような設定の定義が含まれていますが、logwatch によって報告される様々なサービスを定義しています。複数のサービスが同一のログにレポートを出力することはよくあるので必要になります (例: messages, dmesg, boot など)。詳しくは、デフォルトの {{ic|services/}} の設定ファイルを確認してください。

logwatch のメッセージをメールで受け取りたい場合は、[[Postfix]] など sendmail フロントエンドを提供するパッケージをインストールする必要があります。

パッケージにはドキュメントが付属しており設定に関する詳細が載っています。{{ic|/usr/share/logwatch/HOWTO-Customize-LogWatch}} を見て下さい。

==Cron ジョブ==
デフォルトでは {{ic|cron.daily}} に cron ジョブもインストールされます。このジョブは上述の全ての設定ファイルの設定を使います。スクリプトを別の cron フォルダに移動することでレポートの頻度を変更したり、crontab ファイルにカスタム cron ジョブを設定することができます。

セキュリティ

2025-08-03T10:03:34Z

KrisWalton: /* 物理セキュリティ */ 英語版の編集を反映、訳文の修正

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage, expiry, gpasswd, groupmems, [[passwd]], sg, ({{Pkg|shadow}})
* [[FUSE|fusermount3]], fusermount
* pkexec, polkit-agent-helper-1[https://github.com/polkit-org/polkit/pull/501] ([[polkit]])
* [[OpenSSH|ssh-keysign]]
* chfn, chsh, mount, newgrp, umount, wall, write ({{Pkg|util-linux}})
* [[sudo]], {{Pkg|sudo-rs}}, [[doas]], [[su]], su-rs, [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]
* [[Xorg|Xorg.wrap]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識やそこまでの意図はなく、現実に実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、[[カーネルパラメータ]]に{{ic|1=init=/bin/sh}} を設定することでシェルに直接ブートしてログインの制限を回避することができます。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立ちます。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーが秘密情報を保管することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

セキュリティ

2025-07-20T14:08:06Z

KrisWalton: /* ブートローダー */ 誤訳と思われる部分の整理

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage, expiry, gpasswd, groupmems, [[passwd]], sg, ({{Pkg|shadow}})
* [[FUSE|fusermount3]], fusermount
* pkexec, polkit-agent-helper-1[https://github.com/polkit-org/polkit/pull/501] ([[polkit]])
* [[OpenSSH|ssh-keysign]]
* chfn, chsh, mount, newgrp, umount, wall, write ({{Pkg|util-linux}})
* [[sudo]], {{Pkg|sudo-rs}}, [[doas]], [[su]], su-rs, [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]
* [[Xorg|Xorg.wrap]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、[[カーネルパラメータ]]に{{ic|1=init=/bin/sh}} を設定することでシェルに直接ブートしてログインの制限を回避することができます。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

Sysctl

2025-07-18T17:29:15Z

KrisWalton: /* インストール */ 誤訳？

{{Lowercase title}}
[[Category:カーネル]]
[[Category:コマンド]]
[[en:Sysctl]]
[[ru:Sysctl]]
[[Wikipedia:sysctl|sysctl]] は稼働中の[[カーネルパラメータ]]を確認・変更するためのツールです ([[公式リポジトリ]]の {{Pkg|procps-ng}} パッケージ)。sysctl は procfs ({{ic|/proc/}} の仮想プロセスファイルシステム) で実装されています。

== インストール ==

{{Pkg|procps-ng}} パッケージは、{{Pkg|base}} [[メタパッケージ]] の依存関係であるため、すでに [[インストール]] されているはずです。

== 設定 ==

{{Note|バージョン 207 と 21x から、[[systemd]] は {{Ic|/etc/sysctl.d/*.conf}} と {{Ic|/usr/lib/sysctl.d/*.conf}} の設定だけを適用するようになっています。{{Ic|/etc/sysctl.conf}} をカスタマイズしていた場合は、ファイルの名前を {{Ic|/etc/sysctl.d/99-sysctl.conf}} のように変更する必要があります。{{Ic|/etc/sysctl.d/foo}} などのファイルを作成していた場合、{{Ic|/etc/sysctl.d/foo.conf}} と名前を変更してください。}}

'''sysctl''' のプリロード/設定ファイルは {{Ic|/etc/sysctl.d/99-sysctl.conf}} に作成することができます。[[systemd]] では、{{Ic|/etc/sysctl.d/}} と {{Ic|/usr/lib/sysctl.d/}} はカーネルの sysctl パラメータにどちらも使えるディレクトリです。名前と元のディレクトリによって処理される順番が決まります。最後のパラメータによって前の方のパラメータが置き換えられるので順番は重要です。例えば、{{ic|/usr/lib/sysctl.d/50-default.conf}} に書かれたパラメータは {{ic|/etc/sysctl.d/50-default.conf}} や両方のディレクトリよりも後に処理される設定ファイルにある同じパラメータによって置き換えられます。

全ての設定ファイルを手動でロードするには、次を実行します:
# sysctl --system
適用される階層が出力されます。単一のパラメータファイルを指定してロードすることも可能です:
# sysctl -p ''filename.conf''

詳しくは [http://0pointer.de/blog/projects/the-new-configuration-files the new configuration files] や [http://0pointer.de/public/systemd-man/sysctl.d.html systemd の sysctl.d man ページ] を見て下さい。

利用可能なパラメータは {{Ic|/proc/sys/}} 以下に並んでいます。例えば、{{Ic|kernel.sysrq}} パラメータはファイルシステム上の {{Ic|/proc/sys/kernel/sysrq}} ファイルにあたります。{{Ic|sysctl -a}} コマンドを使うことで現在利用可能な値を全て表示することができます。

{{Note|カーネルドキュメントをインストールしている場合 ({{Pkg|linux-docs}})、sysctl 設定に関する詳細な情報が {{Ic|/usr/lib/modules/$(uname -r)/build/Documentation/sysctl/}} で読めます。sysctl 設定を変更する前にこれらを一読することが強く推奨されています。}}

設定の変更はファイルの操作によるか {{Ic|sysctl}} ユーティリティを使って行います。例えば、一時的に[[キーボードショートカット|マジック SysRq キー]]を有効にするには:

# sysctl kernel.sysrq=1

もしくは:

# echo "1" > /proc/sys/kernel/sysrq

再起動後も変更を維持させるには、{{Ic|/etc/sysctl.d/99-sysctl.conf}} や他の {{Ic|/etc/sysctl.d/}} 内の適用されるパラメータファイルに適切な行を追加・編集してください。
{{Tip|適用することができるパラメータがロードされないカーネルモジュールに依存していることもあります。例えば {{ic|/proc/sys/net/bridge/*}} のパラメータは {{ic|br_netfilter}} モジュールに依存しています。モジュールが実行時に (または再起動後) ロードされない場合、パラメータは''ひっそりと''適用されないことになります。[[カーネルモジュール#ロード]]を見て下さい。}}

== セキュリティ ==

[[セキュリティ#カーネルの堅牢化]]を見て下さい。

== ネットワーク ==

=== パフォーマンスを向上させる ===

==== 受信キューのサイズを増やす ====

受信したフレームは、ネットワークカード上のリングバッファから取り出した後、このキューに格納されます。

高速なカードの場合、この値を大きくすると、パケットの損失を防ぐのに役立ちます:

net.core.netdev_max_backlog = 16384

{{Note|SIP ルータなどのリアルタイムな使用用途では、このオプションは高速な CPU を必要とします。そうしないと、キュー内のデータが古くなります。}}

==== 最大接続数を増やす ====

カーネルが受け付ける接続数の上限 (デフォルトは 128):

net.core.somaxconn = 8192

{{Note|1=デフォルト値はカーネル 5.4 で 4096 に上げられました。[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4]}}
{{Warning|この値を大きくしてもパフォーマンスの恩恵を受けられるのはおそらく高負荷なサーバのみです。これにより、処理速度の低下 (例: シングルスレッドのブロッキングサーバ) やワーカー・スレッド/プロセス数の不足が発生する可能性があります。[https://serverfault.com/questions/518862/will-increasing-net-core-somaxconn-make-a-difference/519152]}}

==== ネットワークインターフェイス専用のメモリを増やす ====

{{Accuracy|このセクションは Cloudflare のブログ記事が動機となっているようですが、 [https://github.com/redhat-performance/tuned/blob/master/profiles/network-throughput/tuned.conf#L10 RedHat の調整済みプロファイル]ではさらに小さい値を提案しており、''これは 40 Gb の速度でのみ必要と思われます'' と主張しています。したがって、これらの設定は一般的なハードウェアでは役に立たないようです。}}

デフォルトでは、Linux ネットワークスタックは、WAN リンクを介して高速で大規模なファイル転送をする (つまり、多くのネットワークパケットを扱う) ように設定されていません。正しい値を設定すると、メモリリソースを節約できる場合があります:

net.core.rmem_default = 1048576
net.core.rmem_max = 16777216
net.core.wmem_default = 1048576
net.core.wmem_max = 16777216
net.core.optmem_max = 65536
net.ipv4.tcp_rmem = 4096 1048576 2097152
net.ipv4.tcp_wmem = 4096 65536 16777216

デフォルトの UDP 制限 {{ic|4096}} を増やすこともできます:

net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

詳細および推奨値については、次の資料を参照してください。

* http://www.nateware.com/linux-network-tuning-for-2013.html
* https://blog.cloudflare.com/the-story-of-one-latency-spike/

==== TCP Fast Open を有効にする ====

TCP Fast Open は、Transmission Control Protocol (TCP) の拡張機能であり、送信側の初期 TCP SYN 中にデータを交換できるようにすることで、ネットワーク遅延の低減に役立ちます。[https://www.keycdn.com/support/tcp-fast-open/] デフォルトの {{ic|1}} の代わりに値 {{ic|3}} を使用すると、着信接続と発信接続の両方で TCP Fast Open が許可されます:

net.ipv4.tcp_fastopen = 3

==== 保留中の接続処理を微調整する ====

{{ic|tcp_max_syn_backlog}} は、'Waiting Acknowledgment' 状態の保留接続の最大キュー長です。

SYN フラッド DOS 攻撃を受けた場合、このキューはすぐにいっぱいになってしまいます。その時点で [[Wikipedia:ja:SYN cookies|TCP SYN cookies]] が開始され、システムが正規のトラフィックに応答し続け、悪意のある IP をブロックするためのアクセス権を取得できるようにします。

サーバがピーク時に過負荷になる場合は、この値を少し大きくするとよいかもしれません:

net.ipv4.tcp_max_syn_backlog = 8192

{{ic|tcp_max_tw_buckets}} は TIME_WAIT 状態のソケットの最大数です。

この数に達すると、システムはこの状態のソケットの破棄を開始します。

単純な DOS 攻撃を防ぐには、この値を大きくします:

net.ipv4.tcp_max_tw_buckets = 2000000

{{ic|tcp_tw_reuse}} は、新しいタイムスタンプが以前の接続で記録された最新のタイムスタンプよりも大きい場合に、TCP が TIME-WAIT 状態の既存の接続を新しい発信接続で再利用するかどうかを設定します。

これにより、使用可能なネットワーク・ソケットの不足を回避するのに役立ちます:

net.ipv4.tcp_tw_reuse = 1

ソケットが強制的にクローズされる前に final FIN パケットを待つ秒数を指定します。これは厳密には TCP 仕様に違反しますが、サービス拒否攻撃を防ぐために必要です。Linux 2.2 では、デフォルト値は 180 [https://access.redhat.com/solutions/41776] でした:

net.ipv4.tcp_fin_timeout = 10

{{ic|tcp_slow_start_after_idle}} は、新しい接続に対してだけ TCP をデフォルトのウィンドウサイズで開始するか、またはアイドル状態が長すぎる既存の接続に対してもTCPを開始するかを設定します。

この設定は、永続的な単一接続のパフォーマンスを無効にし、オフにすることもできます:

net.ipv4.tcp_slow_start_after_idle = 0

==== TCP キープアライブパラメータを変更する ====

[[Wikipedia:ja:キープアライブ#TCPキープアライブ|TCPキープアライブ]]は、相手側が応答を停止したかどうかを判断するのに役立つ TCP 接続のメカニズムです。TCP は、アイドル時間が経過すると、ヌルデータを含むキープアライブプローブをネットワークピアに数回送信します。ピアが応答しない場合、ソケットは自動的に閉じられます。デフォルトでは、TCP キープアライブプロセスはソケットのアクティビティを2時間 (7200秒) 待機してから最初のキープアライブプローブを送信し、75秒ごとに再送信します。TCP/IP ソケット通信が行われていてアクティブである限り、キープアライブパケットは必要ありません。

{{Note|次の設定では、アプリケーションは120秒後 (60秒+10秒+10秒+10秒+10秒+10秒+10秒) にデッド TCP 接続を検出します。}}

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 6

==== MTU プローブを有効にする ====

[[Wikipedia:ja:Maximum Transmission Unit|maximum transmission unit (MTU)]] が長いほどパフォーマンスは向上しますが、信頼性は低下します。

これは、パケットが失われると、より多くのデータが再送信されることになり、インターネット上の多くのルータは非常に長いパケットを配信できないためです:

net.ipv4.tcp_mtu_probing = 1

詳細については、https://blog.cloudflare.com/path-mtu-discovery-in-practice/ を参照してください。

==== TCP タイムスタンプ ====

{{Warning|TCP タイムスタンプは、TCP で実装されている (ギガビット単位の速度での) シーケンス番号とラウンドトリップタイム計算におけるオーバーフローから保護してくれます。セキュリティリスクが発生する可能性があるため、TCP タイムスタンプをオフにすることはお勧めしません。[https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf]}}

タイムスタンプ生成を無効にすると、スパイクが減少し、ギガビットネットワークのパフォーマンスが向上する可能性があります:

net.ipv4.tcp_timestamps = 0

==== TCP Selective Acknowledgement ====

TCP Selective Acknowledgement (TCP SACK) は、受信側が損失セグメントに関するより詳細な情報を送信側に与えられるようにして、再転送の量を減らします。これはブーリアン値 {{ic|tcp_sack}} によって制御されます。これは高レイテンシなネットワークにおいて有用ですが、高速な LAN においてはこれを無効化することでスループットを増加させることができます。また、{{ic|tcp_dsack}} も無効化してください。SACK を送信しない場合、D-SACK を送信したくないでしょうから。Forward Acknowledgement は SACK の上で動作し、SACK が無効化されていると Forward Acknowledgement も無効化されます。[https://cromwell-intl.com/open-source/performance-tuning/tcp.html]

net.ipv4.tcp_sack = 1

==== BBR を有効にする ====

[[Wikipedia:TCP congestion control#TCP BBR|BBR 輻輳制御アルゴリズム]]は、インターネットトラフィックのより高い帯域幅とより低いレイテンシを実現するのに役立ちます。まず、{{ic|tcp_bbr}} モジュールを[[カーネルモジュール#手動でモジュールを扱う|ロード]]してください。

{{Note|[https://github.com/google/bbr/blob/master/README BBR の GitHub ページ]には、「これは公式の Google 製品ではありません」と書かれてあります。}}

net.core.default_qdisc = cake
net.ipv4.tcp_congestion_control = bbr

==== エフェメラルポートの範囲を拡大 ====

{{Accuracy|この変更によってパフォーマンスはどのように向上しますか? [[:en:Talk:sysctl#net.ipv4.ip_local_port_range|英語版の議論ページ]]}}

[[Wikipedia:ja:エフェメラルポート|エフェメラルポート]]は通常、Transmission Control Protocol (TCP) 、User Datagram Protocol (UDP) 、または Stream Control Transmission Protocol (SCTP) によって、クライアント/サーバ通信のクライアント側のポート割り当てとして使用されます。

net.ipv4.ip_local_port_range = 30000 65535

=== TCP/IP スタックの強化 ===

IPv4 プロトコルのカーネルのネットワークセキュリティオプションを強化するためのパラメータセットと、同等のものが存在する関連する IPv6 パラメータを次に示します。

システムを [[ルーター]] として使用するなど、一部のユースケースでは、他のパラメータも有用な場合や必要な場合があります。

==== TCP SYN cookie 保護====

SYN flood 攻撃からの保護に役立ちます {{ic|net.ipv4.tcp_max_syn_backlog}} に到達したときにだけ起動します。詳細については、 [https://cateee.net/lkddb/web-lkddb/SYN_COOKIES.html] を参照してください。{{Pkg|linux}} 5.10 以降では、デフォルトで設定されています。

net.ipv 4.tcp_syncookies = 1

==== TCP rfc1337 ====

{{Accuracy|これは TCP 標準の一部ではないようですか?説明が正確でない可能性があります。[https://serverfault.com/questions/787624/why-isnt-net-ipv4-tcp-rfc1337-enabled-by-default]|section=net.ipv4.tcp_rfc1337}}

tcp time-wait assassination hazard から保護し、time-wait 状態のソケットの RST パケットを破棄します。Linux 以外では広くサポートされていませんが、RFC に準拠しています。

net.ipv4.tcp_rfc1337 = 1

==== リバースパスフィルタリング ====

リバースパスフィルタリングを有効にすると、カーネルはマシン上のすべてのインタフェースから受信したパケットのソース検証を行います。これにより、IP スプーフィング方式を使用して被害を与える攻撃者から保護できます。

カーネルのデフォルト値は {{ic|0}} (ソース検証なし) ですが、systemd は {{ic|/usr/lib/sysctl.d/50 default.conf}} を、{{ic|net.ipv 4.conf.all.rp_filter}} を {{ic|2}} (loose mode) [https://github.com/systemd/systemd/pull/10971] に設定して出荷します。

次に、リバースパスフィルタリングメカニズムを value {{ic|1}} (strict モード) に設定します。

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

{{ic|net.ipv4.conf.default.*}}、{{ic|net.ipv4.conf.''interface''.*}} および {{ic|net.ipv4.conf.all.*}} については、 [https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html ip-sysctl.html] を参照してください。

==== martian パケットをログに記録する ====

[[Wikipedia:Martian packet|martian packet]] は、Internet Assigned Numbers Authority (IANA) による特殊な使用のために予約されている送信元アドレスまたは宛先アドレスを指定する IP パケットです。詳細は、[[wikipedia:Reserved_IP_addresses|Reserved IP addresses]] を参照してください。

しばしば martian とルーティング不可能なパケットが危険な目的のために使われるかもしれません。さらなる検査のためにこれらのパケットをログに記録することは有用かもしれません [https://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routable-source-addresses/]

net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.all.log_martians = 1

{{Note|これにより、ログが大量の情報でいっぱいになる可能性があります。テスト用にのみ有効にすることをお勧めします。}}

==== ICMP リダイレクトを無効にする ====

背景は [https://askubuntu.com/questions/118273/what-are-icmp-redirects-and-should-they-be-blocked What are ICMP redirects? Should they be blocked?] です。

ICMP リダイレクト受け入れをディセーブルにするには、次の手順を実行します。

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

ルータ以外で ICMP リダイレクト送信をディセーブルにするには、次の手順を実行します。

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

==== ICMP エコー要求を無視する ====

ICMP エコー (別名 ping) リクエストを無効にするには:

net.ipv4.icmp_echo_ignore_all = 1
net.ipv6.icmp.echo_ignore_all = 1

{{Note|これにより、ICMP エコー応答に依存する監視ツールやアプリケーションで問題が発生する可能性があることに注意してください。}}

=== その他 ===

==== 特権を持たないユーザが IPPROTO_ICMP ソケットを作成できるようにする ====

{{Out of date|{{ic|/usr/lib/sysctl.d/50 default.conf}} は、{{ic|net.ipv4.ping_group_range}} を {{ic|0 2147483647}} に設定します。}}

IPPROTO_ICMP ({{man|7|icmp}}) ソケットタイプを使用すると、{{man|7|raw}} ソケット (CAP_NET_RAW [[ケイパビリティ]] または SUID ビットを適切な特権所有者で開く必要のある操作) を開くことなく、 ICMP_ECHO メッセージを送信し、対応する ICMP_ECHOREPLY メッセージを受信できるようになります。これらの ICMP_ECHO メッセージはアプリケーションによって送信されるため、IPPROTO_ICMP ソケットは ICMP エコーソケットとは別に [[ping]] ソケットとも呼ばれます。

{{ic|ping_group_range}} は、ユーザが IPPROTO_ICMP ソケットを作成できるグループの GID 範囲を決定します。さらに、 CAP_NET_RAW 機能の所有者も IPPROTO_ICMP ソケットを作成することができます。
デフォルトでは、この範囲は {{ic|1 0}}で、root 以外の誰も IPPROTO_ICMP ソケットを作成できないことを意味します。

この設定を利用するには、現在 raw ソケットを使っているプログラムは、代わりに IPPROTO_ICMP ソケットを使うように移植する必要があります。
たとえば、QEMUはSLIRP (User-mode networking) に IPPROTO_ICMP を使用するため、QEMU を実行しているユーザーが IPPROTO_ICMP ソケットを作成できるようにすると、ゲストから ping を実行できるようになります。

GID 100 のグループのメンバーであるユーザーのみが IPPROTO_ICMP ソケットを作成できるようにするには、次のようにします。

net.ipv4.ping_group_range = 100 100

システム内のすべてのユーザーが IPPROTO_ICMP ソケットを作成できるようにするには、次のようにします。

net.ipv4.ping_group_range = 0 65535

== 仮想メモリ ==

Linux カーネルの [[Wikipedia:virtual memory|virtual memory]] サブシステムの動作や、ディスクへのダーティデータの書き出しを調整するための重要なパラメータがいくつかあります。詳細については、公式の [https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html Linux kernel documentation] を参照してください。例:

* {{ic|1=vm.dirty_ratio = 10}}
: 空きページと再利用可能ページを含む使用可能なメモリの合計に対する割合として、ディスク書き込みを生成するプロセスがダーティデータの書き込みを開始するページ数を含みます。

* {{ic|1=vm.dirty_background_ratio = 5}}
: バックグラウンドカーネルフラッシャのスレッドがダーティデータの書き込みを開始するページ数を、空きページと再利用可能ページを含む使用可能なメモリの合計に対する割合として含みます。

パラメータのコメントに記載されているように、これらの値を設定する場合は RAM の合計容量を考慮する必要があります。たとえば、使用可能なメモリの代わりに、インストールされているシステム RAM を使用すると簡単です。

{{Warning|
* 比率の値を大きくすると、パフォーマンスが向上し、データ損失のリスクも高くなります。
* この値を {{ic|0}} に設定すると、ディスクおよびスパイクで待機時間が長くなる可能性があります。
詳細については、https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ を参照してください。
}}

* RAM の {{ic|vm.dirty_ratio}} を 10% に設定することは、RAM が例えば 1GB (10%は {{#expr: 1000/10 round 0}} MB) の場合、妥当な値です。しかし、マシンの RAM がもっと大きい場合、たとえば 16GB (10%は {{#expr: 16/10 round 1 }} GB) になると、回転中のディスクに数秒の書き戻しが行われるため、割合が不釣り合いになることがあります。この場合、より妥当な値は {{ic|3}} です (16GB の 3% は約 491MB です) 。
* 同様に、{{ic|vm.dirty_background_ratio}} を {{ic|5}} に設定することは、メモリ値が小さい場合は問題ありません、RAM 容量を考慮して調整してください。

=== VFS キャッシュ ===

[https://www.kernel.org/doc/html/latest/filesystems/vfs.html virtual file system] (VFS) キャッシュパラメータの値を小さくすると、システムの応答性が向上する場合があります。

* {{ic|1=vm.vfs_cache_pressure = 50}}
: ディレクトリや inode オブジェクトのキャッシュ (VFS キャッシュ) に使用されるメモリをカーネルがどれくらい回収するか制御する値です。デフォルト値の 100 から低くするとカーネルは VFS キャッシュをあまり回収しなくなります (0 に設定してはいけません。メモリ不足状態になる可能性があります)。

== MDADM ==

カーネルがソフトウェア raid デバイスの resync を実行するときは、システムに高負担をかけないように速度を制限しています。sysctl を使って速度制限を上げたり下げたりすることが可能です。

{{bc|1=
# Set maximum and minimum speed of raid resyncing operations
dev.raid.speed_limit_max = 10000
dev.raid.speed_limit_min = 1000
}}

mdadm が {{ic|md_mod}} モジュールとしてコンパイルされている場合、上記の設定はモジュールがロードされた後にのみ使うことができます。{{ic|/etc/sysctl.d}} を使って起動時に設定をロードする場合、{{ic|md_mod}} モジュールは {{ic|/etc/modules-load.d}} で事前にロードすることができます。

== トラブルシューティング ==

=== 定期的にシステムがフリーズする ===

ダーティバイトを十分小さい値に設定 (例えば 4M):

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

{{Note|{{ic|dirty_background_bytes}}および{{ic|dirty_bytes}} パラメータは、{{ic|dirty_background_ratio}} および {{ic|dirty_ratio}} ( [[sysctl#仮想メモリ]] を参照) に対応します。一度に指定できるパラメータは1つだけです。}}

== 参照 ==

* {{man|8|sysctl}} と {{man|5|sysctl.conf}}
* [https://www.kernel.org/doc/Documentation/sysctl/ /proc/sys/ の Linux カーネルドキュメント]
* カーネルドキュメント: [https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt IP Sysctl]
* [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.html sysctl のカーネルネットワークパラメータ]
* [https://sysctl-explorer.net sysctl-explorer.net – an initiative to facilitate the access of Linux' sysctl reference documentation]
* [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-server_security-disable-source-routing Disable Source Routing - Red Hat Customer Portal]
* [https://www.suse.com/documentation/sles11/book_hardening/data/sec_sec_prot_general_kernel.html SUSE handbook about Security Features in the Kernel]

GnuPG

2025-07-05T14:56:25Z

KrisWalton: 使用できなくなったウェブインターフェースを置き換え

[[Category:暗号化]]
[[Category:OpenPGP]]
[[Category:メール]]
[[Category:GNU]]
[[en:GnuPG]]
[[es:GnuPG]]
[[ru:GnuPG]]
[[zh-hans:GnuPG]]
[[zh-hant:GnuPG]]
{{Related articles start}}
{{Related|pacman/パッケージの署名}}
{{Related|保存データ暗号化}}
{{Related|アプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィー}}
{{Related|OpenPGP}}
{{Related articles end}}
[https://www.gnupg.org/ 公式サイト] によれば:

:GnuPG は [https://tools.ietf.org/html/rfc4880 RFC4880] (別名 PGP) で定義される [http://openpgp.org/about/ OpenPGP] 標準の完全でフリーな実装です。GnuPG を使うことでデータや通信を暗号化したり署名することができます。多目的の鍵管理システムであり、あらゆる種類の公開鍵ディレクトリのアクセスモジュールです。GnuPG (またの名を GPG) は他のアプリケーションとの簡単に連携できる機能を備えたコマンドラインツールです。豊富なアプリケーションとライブラリが利用可能です。GnuPG のバージョン2は S/MIME と ssh のサポートも含んでいます。

{{Warning|GnuPG は [[OpenPGP]] 形式の実装として始まりました。しかし、近年、そのメンテナは [[OpenPGP#Standardization|OpenPGP 標準化の取り組み]]、GnuPG 固有の方法で形式を個別に拡張しています ([https://datatracker.ietf.org/doc/draft-koch-librepgp/ draft-koch-librepgp] を参照) これらの変更により、バージョン 2.4 以降の他の実装との互換性の問題が発生します。[[#OpenPGP の互換性]] を参照してください。}}

== インストール ==

{{Pkg|gnupg}} をインストールしてください。

gnupg をインストールすると、GnuPG がパスフレーズエントリに使用するシンプルな PIN やパスフレーズエントリダイアログのコレクションである {{Pkg|pinentry}} もインストールされます。シェルスクリプト {{ic|/usr/bin/pinentry}} は [[#pinentry]] で説明されている順番で、どの ''pinentry'' ダイアログを使用するかを決定します。

グラフィカルフロントエンドや GnuPG と連携するプログラムを使いたい場合は[[アプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィー]]を参照してください。

== 設定 ==

=== 設定ファイルのディレクトリ ===

GnuPG では {{ic|$GNUPGHOME}} によって全ての設定ファイルを保存するディレクトリが指定されます。デフォルトでは {{ic|$GNUPGHOME}} は設定されておらず、代わりに {{ic|$HOME}} が使われます。そのためインストール直後は {{ic|~/.gnupg}} ディレクトリが確認できます。[[自動起動|スタートアップファイル]]に次の行を記述することでデフォルト設定を変更できます:

export GNUPGHOME="''/path/to/directory''"

=== 設定ファイル ===

デフォルトの設定ファイルは {{ic|~/.gnupg/gpg.conf}} と {{ic|~/.gnupg/dirmngr.conf}} です。

デフォルトでは、gnupg ディレクトリの[[ファイルのパーミッションと属性|パーミッション]]は ''700'' に設定されており、ディレクトリのファイルのパーミッションは ''600'' に設定されています。ファイルの読み書きやアクセスの権限を持っているのはディレクトリの所有者だけです (''r'',''w'',''x'')。これはセキュリティ上の理由で設定されていることなので変更してはいけません。ディレクトリやファイルがこのセキュリティ対策に従っていない場合、ファイルやホームディレクトリのパーミッションが安全ではないという警告が表示されます。

どんな長いオプションも設定ファイルに追加します。2つのダッシュを書かないで、オプションや必要な引数の名前を書いて下さい。スケルトンファイルは {{ic|/usr/share/doc/gnupg/}} にあります。gpg がなんらかの操作のため最初に起動されたとき、{{ic|~/.gnupg}} が存在しなければこれらのファイルが {{ic|~/.gnupg}} にコピーされます。[[#参照]] に他の例があります。

また、[[pacman]] がパッケージの署名の検証に使用する設定ファイルは別に存在します。詳しくは [[pacman-key]] を見てください。

=== 新規ユーザーのデフォルトオプション ===

新規ユーザーのデフォルトオプションを設定したい場合、{{ic|/etc/skel/.gnupg/}} に設定ファイルを配置してください。新しいユーザーが追加されると、{{ic|/etc/skel/.gnupg/}} から GnuPG のホームディレクトリにファイルがコピーされます。既存のユーザーのために新しい GnuPG ホームディレクトリを作成できる ''addgnupghome'' というスクリプトも存在します:

# addgnupghome user1 user2

上記のコマンドは {{ic|/home/user1/.gnupg}} と {{ic|/home/user2/.gnupg}} を作成してスケルトンディレクトリからファイルをコピーします。既に GnuPG のホームディレクトリが存在するユーザーはスキップされます。

== 使い方 ==

{{Note|コマンドに ''{{ic|<user-id>}}'' が必要なときは、鍵 ID、指紋、名前やメールアドレスの一部などを指定できます。これについて GnuPG は寛容です。}}

=== 鍵ペアの作成 ===

鍵ペアを生成するにはターミナルに次を入力:

$ gpg --full-gen-key

{{Tip|{{ic|--expert}} を使うことで他の暗号を利用することができます ([[wikipedia:ja:楕円曲線暗号|楕円曲線暗号]]など)。}}

上記のコマンドを実行すると複数の質問がきかれます。大抵の場合、以下の設定が必要になります:

* RSA (署名のみ) と RSA (暗号化のみ) 鍵。
* 鍵長は2048ビットで十分です。4096ビットを使ったところで [https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096 "大した効果はありませんし、無駄に時間がかかるようになるだけです"] 。
* 副鍵の有効期限の設定は技術的には必須ではありませんが、設定することは悪くありません。標準的なユーザーなら、1年間で十分でしょう。たとえ鍵束へのアクセスを失っても、他の人が有効でないことを知ることができるようになります。鍵を作成した後、新しい鍵を再発行しなくても満了日は延長することができます。
* 名前とメールアドレス。後で同じ鍵に別の識別子を追加できます (複数のメールアドレスが存在する場合など)。
* コメントは必要ありません。コメントフィールドのセマンティクスは [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html 定義があやふや] なため、識別子としては限定的です。
* 安全なパスフレーズを選ぶようにしてください ([[セキュリティ#パスワードの管理]]を参照)。

{{Note|入力した名前とメールアドレスは鍵をインポートすれば誰でも確認できるようになります。}}

=== 鍵一覧 ===

* 公開鍵束の鍵の一覧:

$ gpg --list-keys

* 秘密鍵束の鍵の一覧:

$ gpg --list-secret-keys

=== 公開鍵のエクスポート ===

公開鍵暗号で交換されたメッセージの機密性を保証するのが gpg の主な利用法です。互いの鍵束の公開鍵を交換して、メッセージを暗号化するときに使用します。秘密鍵は必ず漏洩しないようにしてください。機密性が破れてしまいます。

他の人があなたに暗号化したメッセージを送れるようにするには、彼らがあなたの公開鍵を知っている必要があります。

(メールで送る場合などのために) ASCII 版の公開鍵を {{ic|''public.key''}} ファイルとして生成するには:

$ gpg --output ''public.key'' --armor --export ''user-id''

あるいは、[[#鍵サーバーを使用する|鍵サーバー]]で鍵を共有する方法もあります。

{{Tip|
* {{ic|--no-emit-version}} を使うか、これを設定ファイルに書くことでバージョン番号の表示を抑制できます。
* {{ic|user-id}} を省略して、キーリング内のすべての公開鍵をエクスポートできます。これは、一度に複数の ID を共有したい場合や、別のアプリケーションにインポートする場合に便利です。例: [[Thunderbird#Use_OpenPGP_with_external_GnuPG|Thunderbird]]。}}

=== 公開鍵のインポート ===

メッセージを暗号化して他の人に送るには、彼らの公開鍵が必要です。公開鍵 ({{ic|''public.key''}}) を自分の公開鍵リングにインポートするには:

$ gpg --import public.key

あるいは、[[#鍵サーバーを使用する|鍵サーバー]]で公開鍵を見つけます。

特定の Arch Linux パッケージをインストールするためにキー ID をインポートしたい場合は、[[pacman-key#キーリングの管理|キーリングの管理]] と [[Makepkg#署名チェック]] を参照してください。

=== 鍵サーバーを使用する ===

==== 鍵の送信 ====

自分の公開鍵を公共の PGP 鍵サーバーに登録することで、他の人があなたに直接連絡することなしにあなたの鍵を入手できるようになります:

$ gpg --send-keys ''user-id''

{{Warning|鍵を鍵サーバーに登録してから、サーバーから鍵を削除することはできません [https://pgp.mit.edu/faq.html]。その理由は、[https://pgp.mit.edu/faq.html MIT PGP Public Key Server FAQ]で説明されています。}}
{{Note|関連するメールアドレスが公開されると、スパムメールの標的となる可能性があり、この場合、スパム対策用のフィルタリングが必要となる場合があります。}}

==== 鍵の検索と受信 ====

鍵サーバーの鍵の情報を確認したい場合、次のコマンドを実行:

$ gpg --search-keys ''user-id''

鍵サーバーから鍵をインポートするには:

$ gpg --recv-keys ''key-id''

{{Warning|
* 誰でも鍵サーバーに鍵を送ることができます。そのため、ダウンロードした鍵が本当にその人のものであると信用してはいけません。入手した鍵の指紋を、持ち主が別の場所(ブログ、サイト、メール・電話で連絡するなど)で公開している指紋と比較してその鍵の真正性を確かめるべきです。複数の情報源を使うことでその鍵の信頼性は増します。[[Wikipedia:Public key fingerprint]] を参照。
* ID が短いと衝突する可能性があります。インポートされた鍵には全て短い ID が割り当てられます。鍵を受け取るときに完全な指紋か長い鍵 ID を使うことで衝突を回避できます [https://lkml.org/lkml/2016/8/15/445]。
}}

{{Tip|{{ic|auto-key-retrieve}} を {{ic|gpg.conf}} に追加すると、必要に応じて鍵サーバから鍵を自動的に取得しますが、これは '''プライバシー侵害''' と見なされる可能性があります。{{man|1|gpg}} の "web bug" を参照。}}

==== 鍵サーバー ====

最も一般的な鍵サーバーは次の通りです:

* [https://keyserver.ubuntu.com Ubuntu Keyserver]: 分散型、検証なし、キーは削除不可。
* [https://keys.mailvelope.com Mailvelope Keyserver]: 中央型、E メール ID の検証、キーは削除可能。
* [https://keys.openpgp.org keys.openpgp.org]: 中央型、E メール ID の検証、キーは削除可能。サードパーティの署名無し (つまり、Web of Trust のサポートは無し)。

[[Wikipedia:Key server (cryptographic)#Keyserver examples]] にその他の鍵サーバもあります。

代替の鍵サーバは、[[#設定ファイル]]のうちどれかで {{ic|keyserver}} オプションを使用することによって指定することができます。例えば:

{{hc|~/.gnupg/dirmngr.conf|
keyserver hkp://keyserver.ubuntu.com
}}

いつも使用しているサーバが思うように動かない時に、一時的に別のサーバを使用すると便利です。例えば、以下のようにして別のサーバを使用できます:

$ gpg --keyserver ''hkps://keys.openpgp.org/'' --search-keys ''user-id''

{{Tip|
* デフォルトの hkps 鍵サーバプールを使用していて、{{ic|gpg: keyserver receive failed: General error}} というメッセージで失敗する場合、{{ic|dirmngr.conf}} 内で {{ic|hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem}} を使用して HKPS プールの検証証明書を設定し、古い dirmngr プロセスを kill してください。
* {{ic|gpg: keyserver receive failed: Connection refused}} というメッセージで失敗する場合、別の DNS サーバを使ってみてください。
* [[Tor#Torsocks]] で [[Tor]] 経由で鍵サーバに接続することもできます。また、{{ic|--use-tor}} コマンドラインオプションもあります。詳細は [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html] を参照してください。
* {{ic|http_proxy}} [[環境変数]]を設定し、{{ic|dirmngr.conf}} 内で {{ic|honor-http-proxy}} を設定すれば、プロキシを使って鍵サーバに接続することもできます。また、設定ファイル内で {{ic|http-proxy ''host[:port]''}} を使えば、先の環境変数をオーバーライドすることができます。変更を適用するには、{{ic|dirmngr.service}} [[ユーザーユニット]]を[[再起動]]してください。
* {{ic|gpg: keyserver receive failed: Server indicated a failure}} というメッセージで鍵サーバに接続できない場合、別のポートを使用するように gpg を設定する必要があるのかもしれません。例えば、Ubuntu の鍵サーバで80番ポートを使用するには、{{ic|keyserver hkp://keyserver.ubuntu.com:80}} と設定してください。
}}

=== Web Key Directory ===

Web Key Service (WKS) プロトコルは、鍵配布のための新しい [https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ 標準]で、電子メールドメインが [https://wiki.gnupg.org/WKD Web Key Directory (WKD)] という独自の鍵サーバーを提供するものです。電子メールアドレス (例 : {{ic|user@example.com}}) に暗号化するとき、GnuPG (>=2.1.16) は、公開鍵をローカル鍵束にまだ持っていなければ、 HTTPS でそのドメイン ({{ic|example.com}}) に照会します。オプション {{ic|auto-key-locate}} は、このメールアドレスのローカル鍵束に鍵がない場合、WKD プロトコルを使って鍵を探します。

# gpg --recipient ''user@example.org'' --auto-key-locate --encrypt ''doc''

WKD をサポートしているメールプロバイダーの一覧は [https://wiki.gnupg.org/WKD#Implementations GnuPG Wiki] を参照してください。メールアドレスのドメインを自分で管理している場合は、[https://wiki.gnupg.org/WKDHosting このガイド]に従って、自分のドメインで WKD を有効にすることができます。あなたの鍵が WKD で見つかるかどうかを確認するには、[https://wkd.dp42.dev/ このウェブインターフェイス]が使用できます。

=== 暗号化と復号化 ===

==== 非対称 ====

暗号化や復号化をするときは複数の秘密鍵を使用することが可能です。複数の鍵を使うときは使用する鍵を選択する必要があります。{{ic|-u ''<user-id>''}} オプションや {{ic|--local-user ''<user-id>''}} オプションを使うことで選択できます。このオプションを使うとデフォルトの鍵を使用する代わりに指定された鍵を使用します。先に[[#鍵の作成]]が必要です。

(テキストでメッセージをコピー&ペーストするのに適している) ASCII armor を使ってファイルを暗号化するには、次を使用:

$ gpg --encrypt --armor secret.txt

単に暗号化だけしたいときは {{ic|--armor}} は不要です。

{{Tip|
* 受取人を変更したい場合は {{ic|-r ''<user-id>''}} (または {{ic|--recipient ''<user-id>''}}) オプションで変更できます。
* 暗号メッセージに受取人の鍵 ID を入れたくないときは {{ic|--recipient}} のかわりに {{ic|-R ''<user-id>''}} または {{ic|--hidden-recipient ''<user-id>''}} を追加してください。メッセージの受取人を隠蔽して、トラフィックの解析に対する対抗策になります。
* バージョン番号を出力したくないときは {{ic|--no-emit-version}} を追加してください。または設定ファイルに同じ設定を追加してください。}}

{{Note|gnupg を使えば機密文書を暗号化できますが、一度に複数のファイルを暗号化することはできません。ディレクトリやファイルシステム全体を暗号化したいときは、[[TrueCrypt]] や [[EncFS]] などを使用するか、tarball にファイルをまとめて暗号化すると良いでしょう。}}

ファイルを復号化するには、次のコマンドを使用:

$ gpg --decrypt secret.txt.asc

パスフレーズの入力が求められます。復号化するには送信者の公開鍵をインポートしてある必要があります。

==== 対称 ====
対称暗号化では鍵を生成する必要がなくパスフレーズだけでデータを暗号化できます。対称暗号化を使用するするには {{ic|--symmetric}} または {{ic|-c}} を使用します:

$ gpg -c ''doc''

例:

* パスフレーズを使って対称暗号で {{ic|''doc''}} を暗号化。
* AES-256 暗号アルゴリズムを使ってパスフレーズを暗号化。
* SHA-512 ダイジェストアルゴリズムを使ってパスフレーズをハッシュ化。
* 65536回繰り返しパスフレーズをハッシュ化。

$ gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 ''doc''

対称暗号化された {{ic|''doc''.gpg}} をパスフレーズで復号化して {{ic|''doc''}} として同じディレクトリに出力するには:

$ gpg --output ''doc'' --decrypt ''doc''.gpg

==== ディレクトリ ====

ディレクトリの暗号化・復号化は {{man|1|gpgtar}} で行うことができます。

暗号化:
$ gpgtar -c -o ''dir''.gpg ''dir''

復号化:
$ gpgtar -d ''dir''.gpg

== 鍵の管理 ==

=== 秘密鍵のバックアップ ===

秘密鍵をバックアップするには以下を実行:

$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''

''gpg'' のリリース 2.1 からデフォルトの挙動が変わっており、たとえ鍵の作成時にパスワードを設定しなかった場合でも上記のコマンドを実行したときにパスフレーズによる保護が必須になっています。エクスポートされたファイルを入手してしまえば、パスフレーズを知らなくてもファイルを暗号化したり署名を加えることができてしまうためです。

{{Warning|パスフレーズは秘密鍵の最大の弱点となります。暗号化されたコンテナやドライブなど、秘密鍵は安全な場所に保管してください。}}

秘密鍵のバックアップをインポートするには:
$ gpg --import ''privkey.asc''

=== 失効証明書のバックアップ ===

失効証明書は、新しく生成されたキーに対して自動的に生成されます。これらはデフォルトで {{ic|~/.gnupg/openpgp-revocs.d/}} にあります。証明書のファイル名は、取り消すキーのフィンガープリントです。
失効証明書は、ユーザーが後で次を使用して手動で生成することもできます。

$ gpg --gen-revoke --armor --output ''revcert.asc'' ''user-id''

この証明書は、紛失または侵害された場合に [[#鍵の取り消し]] に使用できます。バックアップは、秘密鍵にアクセスできなくなったため、上記のコマンドで新しい失効証明書を生成できない場合に役立ちます。必要に応じて印刷して手で入力できるほど短いです。

{{Warning|失効証明書にアクセスできる人は誰でも、キーを公に失効させることができます。このアクションは元に戻すことはできません。秘密鍵を保護するのと同じように、失効証明書を保護します。}}

=== 鍵の編集 ===

* {{ic|gpg --edit-key ''<user-id>''}} コマンドを実行するとメニューが表示され、鍵管理に関連するほとんどの作業を行うことができます。以下は満了日を設定する例です:

$ gpg --edit-key ''<user-id>''
> key ''number''
> expire ''yyyy-mm-dd''
> save
> quit

便利なコマンド:
> passwd # change the passphrase
> clean # compact any user ID that is no longer usable (e.g revoked or expired)
> revkey # revoke a key
> addkey # add a subkey to this key
> expire # change the key expiration time

* 公開鍵の ASCII バージョンを生成 (例: メールなどで配るため):

$ gpg --armor --output public.key --export ''<user-id>''

* PGP 公開鍵サーバーに鍵を登録して、他の人があなたに直接連絡しなくても鍵を取得できるようにする:

$ gpg --keyserver pgp.mit.edu --send-keys ''<key-id>''

* ユーザー Bob あてに署名と暗号化:

$ gpg -se -r Bob ''file''

* クリアテキスト署名を作成:

$ gpg --clearsign ''file''

=== 副鍵のエクスポート ===

複数のデバイスで同じ鍵を使い回す場合、マスター鍵を分離させて、セキュリティが低いシステムでは暗号化に必要な副鍵だけを使いたいという状況が考えられます。

まず、エクスポートしたい副鍵を確認してください:

$ gpg -K

エクスポートする副鍵だけを選択:

$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg

{{Warning|''!'' を追加するのを忘れると、全ての副鍵がエクスポートされます。}}

ここで作業を終えても良いですが、パスフレーズの変更もしておくと安全です。一時フォルダに鍵をインポートします:

$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg
$ gpg --homedir /tmp/gpg --edit-key ''<user-id>''
> passwd
> save
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg

{{Note|マスター鍵が存在しない、また、マスター鍵のパスワードが変更されていないという警告が表示されますが、変更したのは副鍵のパスワードなので無視してかまいません。}}

これで、他のデバイスで {{ic|/tmp/subkey.altpass.gpg}} を使うことができます。

=== 有効期限の延長 ===

{{Warning|何か特段の事情がないかぎり、有効期限が切れたり無効になった副鍵を削除しないでください。削除してしまうとその副鍵で暗号化したファイルを復号化できなくなってしまいます。満了した、または無効のキーを削除するのは他のユーザーの鍵束を整理するときだけにしてください。}}

副鍵を設定して一定期間後に満了したら、新しい副鍵を作成できます。他のユーザーが鍵束を更新できるように数週間前に行うようにしましょう。

{{Note|新しい鍵を作成する必要はありません。期限がきて使えなくなっただけだからです。有効期間を延長することができます。}}

* 新しい副鍵を作成 (署名と暗号化の鍵の両方)

$ gpg --edit-key ''<user-id>''
> addkey

そして質問に答えて下さい (推奨される設定については前のセクションを参照)。

* 変更を保存:

> save

* 鍵サーバーにアップデート:

$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''

また、この鍵を複数のコンピュータで使用する場合は、公開鍵(新しい署名付き有効期限付き)をエクスポートして、それらのマシンでインポートすることもできます。

$ gpg --export --output pubkey.gpg ''user-id''
$ gpg --import pubkey.gpg

秘密鍵の再エクスポートやバックアップの更新は必要ありません。マスター秘密鍵自体に有効期限がなく、公開鍵やサブ鍵に残された有効期限の署名があればよいのです。

=== サブキーのローテーション ===

{{Warning|'''絶対に'''期限切れまたは失効した自分のサブキーを削除しないでください。削除すると、古いサブキーで暗号化されたファイルを復号できなくなります。他のユーザーの期限切れまたは失効したキーを削除してキーリングを整理する場合のみ行ってください。}}

また、期限切れのサブキーを完全に使用しないようにすることもできます。その場合、新しいサブキーを作成します。キーリングの更新期間を考慮し、数週間前に行うことを推奨します。

{{Tip|期限切れになったからといって、新しい鍵を作成する必要はありません。有効期限を延長することも可能です。詳細は [[#有効期限の延長]] を参照してください。}}
新しいサブキーの作成(署名用と暗号化用の両方に対して実行)

$ gpg --edit-key ''user-id''
> addkey

その後、表示される質問に答えます(推奨設定については [[#鍵ペアの作成]] を参照)

変更の保存

> save

キーサーバーへの更新

$ gpg --keyserver pgp.mit.edu --send-keys ''user-id''

また、秘密鍵のバックアップのために、新しい秘密鍵のコピーをエクスポートする必要があります。詳細は [[#秘密鍵のバックアップ]] を参照してください。

{{Tip|期限切れのサブキーを失効させる必要はなく、むしろ悪い印象を与える可能性があります。頻繁に鍵を失効させると、他者からの信用を失う原因となることがあります。}}

=== 鍵の取り消し ===

鍵が侵害された、置き換えられた、使用されなくなった、またはパスフレーズを忘れた場合は、キーの取り消しを実行する必要があります。これは、鍵を鍵の失効証明書とマージすることによって行われます。

鍵ペアにアクセスできなくなった場合は、まず[[#公開鍵のインポート]]して独自の鍵をインポートします。
次に、キーを失効させるために、[[#失効証明書のバックアップ]] で保存したファイルをインポートします。

$ gpg --import ''revcert.asc''

ここで、取り消しを公開する必要があります。 [[#鍵サーバーを使用する]]で過去に PGP サーバーを使用したことがある場合は、取り消された鍵を公開 PGP サーバーに送信します。それ以外の場合は、取り消された鍵をファイルにエクスポートし、通信パートナーに配布します。

== 署名 ==

署名は文章を証明します。文章が改変された場合、署名の検証に失敗します。公開鍵を使用して文章を暗号化する暗号化とは違って、署名はユーザーの秘密鍵を使って作成されます。署名された文章を受け取った人は送り主の公開鍵を使って署名を検証できます。

=== 署名の作成 ===

==== ファイルに署名する ====

ファイルに署名するには {{ic|--sign}} または {{ic|-s}} フラグを使います:

$ gpg --output ''doc.sig'' --sign ''doc''

上記のコマンドは暗号化も行ってファイルをバイナリ形式で保存します。

==== ファイルやメッセージにクリア署名 ====

バイナリ形式に圧縮しないでファイルに署名するには:

$ gpg --clearsign ''doc''

上記のコマンドは文章を ASCII-armored 署名でラッピングしますが、文章に変更は加えられません。

==== 分離署名を作成する ====

文章やファイルとは別に署名ファイルを作成したい場合、{{ic|--detach-sig}} フラグを使ってください:

$ gpg --output ''doc.sig'' --detach-sig ''doc''

上記の方法はソフトウェアプロジェクトを配布するときによく用いられます。署名書を検証することで第三者によってファイルが改竄されていないことが確認できます。

==== 署名の検証 ====

署名を検証するには {{ic|--verify}} フラグを使います:

$ gpg --verify ''doc.sig''

{{ic|''doc.sig''}} は検証したい署名に置き換えてください。

ファイルの検証と復号化を同時に行いたいお場合、{{ic|--decrypt}} フラグを使ってください。

分離署名を検証する場合、ファイルと署名の両方が必要になります。例えば、Arch Linux の ISO を検証する場合:

$ gpg --verify ''archlinux-''version''.iso.sig''

{{ic|archlinux-''version''.iso}} が同じディレクトリに存在していなければなりません。

=== 署名の確認 ===

署名を確認するには、{{ic|--verify}} フラグを使用します。

$ gpg --verify ''doc''.sig

ここで {{ic|''doc''.sig}} は、検証したい署名を含む署名付きファイルです。

分離された署名を検証する場合、署名されたデータファイルと署名ファイルの両方が検証時に存在する必要があります。例えば、Arch Linux の最新の iso を検証する場合、次のようになります。

$ gpg --verify archlinux-''version''.iso.sig

ここで {{ic|archlinux-''version''.iso}} は同じディレクトリにある必要があります。

また、第2引数で署名付きデータファイルを指定することも可能です。

$ gpg --verify archlinux-''version''.iso.sig ''/path/to/''archlinux-''version''.iso

署名に加えて暗号化されている場合は、[[#暗号化と復号化|復号化]]を行うだけで署名も検証されます。

== gpg-agent ==

''gpg-agent'' はキーチェインにパスワードをリクエストしたりキャッシュしたりするのに使われるデーモンです。メールクライアントなど外部のプログラムから GnuPG を利用する場合に便利です。{{Pkg|gnupg}} には [[systemd/ユーザー|systemd ユーザー]]ソケットが付属しており、デフォルトで有効になります: {{ic|gpg-agent.socket}}, {{ic|gpg-agent-extra.socket}}, {{ic|gpg-agent-browser.socket}}, {{ic|gpg-agent-ssh.socket}}, {{ic|dirmngr.socket}}。

* ''gpg'' はメインの {{ic|gpg-agent.socket}} を使って ''gpg-agent'' デーモンに接続します。
* {{ic|gpg-agent-extra.socket}} はリモート環境から Unix ドメインソケットの転送を設定します。秘密鍵をリモート環境に移さなくてもリモート環境で ''gpg'' が使えるようになります。詳しくは {{man|1|gpg-agent}} を参照。
* The {{ic|gpg-agent-browser.socket}} allows web browsers to access the ''gpg-agent'' daemon.
* [[SSH]] は {{ic|gpg-agent-ssh.socket}} を使って ''ssh-add'' プログラムによって追加された [[SSH 鍵]]をキャッシュします。必要な設定は [[#SSH エージェント]]を見てください。
* {{ic|dirmngr.socket}} は鍵サーバーへの接続を処理する GnuPG デーモンを起動します。

{{Note|GnuPG の設定ファイルのディレクトリがデフォルトと異なる場合、{{ic|gpgconf --list-dirs}} の値を使用するようにソケットファイルを編集してください。}}

=== 設定 ===

gpg-agent は {{ic|~/.gnupg/gpg-agent.conf}} ファイルで設定することができます。設定オプションは {{man|1|gpg-agent}} に記載されています。例えば、未使用の鍵の cache ttl を変更することができます:

{{hc|~/.gnupg/gpg-agent.conf|
default-cache-ttl 3600
}}

{{Tip|セッションを通してパスフレーズをキャッシュするには、次のコマンドを実行してください:
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX

XXXX は鍵輪に置き換えてください。鍵輪の値は {{ic|gpg --with-keygrip -K}} を実行することで取得できます。パスフレーズは {{ic|gpg-agent}} が再起動されるまで保存されます。{{ic|default-cache-ttl}} の値を設定した場合、そちらが優先されます。
}}

=== エージェントのリロード ===

設定を変更した後は、{{ic|gpg-connect-agent}} でエージェントをリロードしてください:

$ gpg-connect-agent reloadagent /bye

シェルに {{ic|OK}} と出力されます。

しかし、エージェント設定に {{ic|keep-screen}} が追加されている場合など、再起動だけでは十分でないこともあります。
この場合、まず進行中の gpg-agent プロセスを kill してから、上記で説明したように再起動する必要があります。

=== pinentry ===

{{ic|gpg-agent}} は {{ic|pinentry-program}} stanza を使用して、パスフレーズの入力を促す際に、特定の {{Pkg|pinentry}} ユーザーインターフェイスを使用するように設定できます。例えば、以下の通りです。

{{hc|~/.gnupg/gpg-agent.conf|
pinentry-program /usr/bin/pinentry-curses
}}

他のも様々な pinentry プログラムがあります。{{ic|pacman -Ql pinentry {{!}} grep /usr/bin/}} を参照してください。

{{Tip|{{ic|/usr/bin/pinentry-kwallet}} を使うには {{AUR|kwalletcli}} パッケージをインストールする必要があります。}}

変更を行った後は、[[#エージェントのリロード|エージェントのリロード]]を忘れないでください。

=== パスワードのキャッシュ ===

GnuPG のパスワードをセッションの間だけ記憶させたい場合、{{ic|max-cache-ttl}} と {{ic|default-cache-ttl}} を高い値に設定してください:

{{hc|
gpg-agent.conf|
max-cache-ttl 60480000
default-cache-ttl 60480000
}}

詳しくは [[#gpg-agent]] を参照。

=== 無人のパスフレーズ ===

GnuPG 2.1.0 から gpg-agent と pinentry の利用が必須になりました。これによって {{ic|--passphrase-fd 0}} コマンドラインオプションによって STDIN からパイプで渡されたパスフレーズの後方互換性が損ねられています。古いリリースと同じような機能を使うには2つのことをする必要があります:

まず、gpg-agent の設定を編集して ''loopback'' pinentry モードを許可してください:

{{hc|1=~/.gnupg/gpg-agent.conf|2=
allow-loopback-pinentry
}}

gpg-agent プロセスが実行している場合は再起動して変更を適用します。

次に、更新する必要があるアプリケーションに以下のようにコマンドラインパラメータを含めて loopback モードを使用します:

$ gpg --pinentry-mode loopback ...

もしくは、コマンドラインで設定ができない場合、オプションを設定に追加します:

{{hc|1=~/.gnupg/gpg.conf|2=
pinentry-mode loopback
}}

{{Note|上流の開発者は ''gpg.conf'' で ''pinentry-mode loopback'' を設定すると他の機能が使えなくなる可能性があると示唆しています。できるかぎりコマンドラインオプションを使うようにして下さい [https://bugs.g10code.com/gnupg/issue1772]。}}

=== SSH エージェント ===

''gpg-agent'' には OpenSSH エージェントのエミュレーション機能が存在します。既に GnuPG スイートを使っているのであれば、SSH 鍵をキャッシュするのに使うことが可能です。さらに、パスフレーズを管理するのに GnuPG エージェントの PIN エントリダイアログを使えます。

==== SSH_AUTH_SOCK の設定 ====

SSH が ''ssh-agent'' の代わりに ''gpg-agent'' を使うように {{ic|SSH_AUTH_SOCK}} を設定してください。シェルのタイプに関係なくプロセスが ''gpg-agent'' インスタンスを使うようにするには [[環境変数#pam_env を使う|pam_env]] を使用します:

{{hc|~/.pam_environment|2=
SSH_AGENT_PID DEFAULT=
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
}}

{{note|
* {{ic|SSH_AUTH_SOCK}} を手動で設定する場合、{{ic|GNUPGHOME}} をカスタマイズしているときはソケットの場所が異なる可能性があるので注意してください。以下の bash の例を使用するか、{{ic|SSH_AUTH_SOCK}} を {{ic|gpgconf --list-dirs agent-ssh-socket}} の値に変更してください。
* GNOME Keyring がインストールされている場合、その ssh コンポーネントを[[GNOME/Keyring#無効化する|無効化]]する必要があります。そうしないと、{{ic|SSH_AUTH_SOCK}} を上書きしてしまいます。}}

または、Bash を使う場合:

{{hc|~/.bashrc|<nowiki>
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
</nowiki>}}

{{Note|1=<nowiki></nowiki>エージェントを {{ic|gpg-agent --daemon /bin/sh}} で起動している場合、シェルは {{ic|SSH_AUTH_SOCK}} 変数を ''gpg-agent'' から承継します [http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/gpg-agent.c;hb=7bca3be65e510eda40572327b87922834ebe07eb#l1307]。}}

==== 適切な TTY を使うように pinentry を設定 ====

{{man|1|gpg-agent}} にあるように、ユーザーを X セッションに切り替えた場合は GPG_TTY も設定して TTY を更新してください。例:

{{hc|~/.bashrc|<nowiki>
# Set GPG TTY
export GPG_TTY=$(tty)

# Refresh gpg-agent tty in case user switches into an X session
gpg-connect-agent updatestartuptty /bye >/dev/null
</nowiki>}}

複数の端末を同時に使用し、''ssh'' コマンドを実行した同じ端末から ''pinentry-curses'' で ''gpg-agent'' がパスフレーズを要求するようにしたい場合、SSH 設定ファイルに以下を追加してください。これにより、''ssh'' コマンドを実行するたびに TTY がリフレッシュされるようになります [https://unix.stackexchange.com/a/499133]。

{{hc|~/.ssh/config|2=
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
}}

なお、環境変数 GPG_TTY が設定されていないと動作しません。

==== SSH 鍵の追加 ====

''gpg-agent'' が起動していれば [[SSH 鍵#ssh-agent|ssh-agent]] と同じように ''ssh-add'' で鍵を追加できます。追加された鍵は {{ic|~/.gnupg/sshcontrol}} ファイルに保存されます。パスフレーズが必要になったときは毎回 ''pinentry'' ダイアログが表示されます。パスフレーズのキャッシュは {{ic|~/.gnupg/gpg-agent.conf}} ファイルで制御します。以下の例では ''gpg-agent'' で鍵を3時間キャッシュします:

{{hc|~/.gnupg/gpg-agent.conf|
default-cache-ttl-ssh 10800
max-cache-ttl-ssh 10800}}

==== SSH 認証に PGP 鍵を使用する ====

PGP 鍵を SSH 鍵として使うこともできます。鍵のメンテナンスを楽にして SSH 鍵をキーカードに保存できます。認証機能を有効にして鍵を作成する必要があります ([[#カスタム機能]]を参照)。SSH 認証に PGP 鍵を使用することで得られる様々な利点があります。

* SSH キーを維持する必要がなくなるため、キーのメンテナンスが削減されます。
* 認証キーをスマートカードに保存する能力。GnuPG はカードが利用可能なときにキーを自動的に検出し、エージェントに追加します({{ic|ssh-add -l}} または {{ic|ssh-add -L}} で確認)。キーのコメントは次のようなものであるべきです:{{ic|openpgp:''key-id''}} または {{ic|cardno:''card-id''}}。

GPG/SSH キーの公開キー部分を取得するには、{{ic|gpg --export-ssh-key ''gpg-key''}} を実行します。キーが認証可能であっても、このコマンドが "Unusable public key" で失敗する場合は、{{ic|!}} サフィックスを追加します ([https://dev.gnupg.org/T2957])。

GPG キーをキーカードに持っていない場合、SSH キーとして認識されるように {{ic|$GNUPGHOME/sshcontrol}} にキーを追加する必要があります。キーがキーカードにある場合、その keygrip は {{ic|sshcontrol}} に暗黙的に追加されます。そうでない場合、次の方法でキーの keygrip を取得します:

{{hc|$ gpg --list-keys --with-keygrip|2=
sub rsa4096 2018-07-25 [A]
Keygrip = ''1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7''
}}

その後、{{ic|sshcontrol}} をこのように編集します。keygrip を追加するのは一度だけの操作です。追加のキーを追加する場合を除いて、ファイルを再度編集する必要はありません。

{{hc|$GNUPGHOME/sshcontrol|
''1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7''
}}

== スマートカード ==

GnuPG は、スマートカードリーダとのインターフェイスとして ''scdaemon'' を使用します。詳細は {{man|1|scdaemon}} [[man ページ]]を参照してください。

=== GnuPG のみ設定 ===

{{Note|scdaemon が USB スマートカードリーダに直接アクセスできるようにするには、任意の依存パッケージである {{Pkg|libusb-compat}} をインストールする必要があります。}}

GnuPG ベース以外のカードを使う予定がない場合は、{{ic|~/.gnupg/scdaemon.conf}} の {{Ic|reader-port}} パラメータを確認してください。'0' が最初に利用できるシリアルポートリーダーを、'32768' (デフォルト) が最初の USB リーダーを示しています。

=== GnuPG と pcscd (PCSC Lite) ===

{{man|8|pcscd}} は、スマートカードへのアクセスを管理するデーモンです (SCard API)。(GnuPG の内臓の CCID サポートを使うなどして) GnuPG の scdaemon でスマートカードと直接接続できない場合、このデーモンは PCSC Lite ドライバを使用するスマートカードを見つけようとします。

pscsd を使うには、{{Pkg|pcsclite}} と {{Pkg|ccid}} を[[インストール]]してください。そして、{{ic|pcscd.service}} を[[開始]]し、(このサービスを永続的に使用する場合は) [[有効化]]してください。あるいは、{{ic|pcscd.socket}} を開始/有効化することで、必要なときにだけデーモンをアクティブ化させることもできます。

==== 常に pcscd を使う ====

opensc ドライバを使用するスマートカード (一部の国々の ID カードがこれに該当します) を使う場合は、GnuPG の設定に注意する必要があります。特に設定しないと、{{Ic|gpg --card-status}} を実行した時に以下のようなメッセージが表示されるかもしれません:

gpg: selecting openpgp failed: ec=6.108

デフォルトでは、scdaemon はデバイスに直接接続しようとします。カードリーダが他のプロセスによって使用されている場合、この接続は失敗します。例えば、pcscd デーモンが OpenSC によって使用されている場合などです。この問題を解決するには、scdaemon と opensc が互いにうまく機能するようにするために、opensc のものと同じドライバを使用する必要があります。scdaemon が pcscd を使用するようにするには、{{ic|~/.gnupg/scdaemon.conf}} から {{Ic|reader-port}} を削除し、{{ic|libpcsclite.so}} ライブラリへのパスを指定し、pcscd を確実に使用させるために ccid を無効化する必要があります:

{{hc|~/.gnupg/scdaemon.conf|<nowiki>
pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid
</nowiki>}}

OpenSC を使用しない場合は、{{man|1|scdaemon}} を確認してください。

==== pcscd との共有アクセス ====

GnuPG {{ic|scdaemon}} は、{{ic|pcscd}} への接続時に {{ic|PCSC_SHARE_EXCLUSIVE}} フラグを使用する唯一の一般的な {{ic|pcscd}} クライアントです。[[Electronic identification|電子識別]] にリストされているブラウザやプログラムで使用される OpenSC PKCS#11 などの他のクライアントは、単一のスマートカードへの同時アクセスを許可する {{ic|PCSC_SHARE_SHARED}} を使用しています。{{ic|pcscd}} は、他のクライアントが接続されている間はスマートカードへの排他的アクセスを与えません。これは、GnuPG スマートカード機能を使用するには、開いているブラウザウィンドウをすべて閉じるか、その他の不便な操作を行う必要があることを意味します。バージョン 2.2.28 LTS および 2.3.0 以降では、{{ic|scdaemon.conf}} ファイルを変更し、その行末に {{ic|pcsc-shared}} を追加することで共有アクセスを有効にできます。

===== マルチアプレットスマートカード =====

OpenSC PKCS#11 で [[YubiKey]] または他のマルチアプレット USB ドングルを使用すると、OpenSC が Yubikey を OpenPGP から PIV アプレットに切り替えて、{{ic|scdaemon}} が壊れるという問題が発生する可能性があります。

OpenSC に OpenPGP アプレットも使用させることで、この問題を回避できます。{{ic|/etc/opensc.conf}} ファイルを開き、Yubikey を検索して、{{ic|1=driver = "PIV-II";}} 行を {{ic|1=driver = "openpgp";}} に変更します。そのようなエントリがない場合は、{{ic|pcsc_scan}} を使用します。リセットするための答えを検索して {{ic|ATR: 12 34 56 78 90 AB CD ...}} 次に、新しいエントリを作成します。

{{hc|/etc/opensc.conf|2=
...
card_atr 12:23:34:45:67:89:ab:cd:... {
name = "YubiKey Neo";
driver = "openpgp"
}
...
}}

その後、{{ic|pkcs11-tool -O --login}} を使用して、OpenPGP アプレットがデフォルトで選択されていることをテストします。この変更を適用するには、ブラウザなどの他の PKCS#11 クライアントを再起動する必要があります。

===== SSH 経由でリモートクライアント上のスマートカードを使用する =====

SSH 経由でマシンにログインし、pcscd 経由で接続されたデバイスを使用しようとすると、次のようなエラーが発生します:

gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

これは、[[Polkit]] がローカルクライアントへのアクセスを制限しているためです。これを修正するには、特定のユーザーを許可するルールを追加します。以下のルールにより、{{ic|wheel}} グループ内のすべてのユーザーが {{ic|pcscd}} 経由でデバイスにアクセスできます:

{{hc|/etc/polkit-1/rules.d/99-pcscd.rules|2=
polkit.addRule(function(action, subject) {
if (action.id == "org.debian.pcsc-lite.access_card" &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
polkit.addRule(function(action, subject) {
if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
}}

ファイルを作成したら、必ず {{ic|polkit.service}} を [[再起動]] してください。

== OpenPGP の互換性 ==

GnuPG は [[OpenPGP]] 形式の実装として始まりました。現在、プロジェクトは [https://www.rfc-editor.org/rfc/rfc4880.html RFC 4880] に基づいており、[https://www.rfc-editor.org/rfc/rfc9580.html RFC 9580] (RFC 4880 に代わる) はサポートしていません。

ただし、バージョン 2.4.0 (2022 年 12 月以降) 以降、GnuPG は IETF プロセスの外でフォーマットへの変更と拡張をロールアウトすることを選択しました ([https://datatracker.ietf.org/doc/draft-koch-librepgp/ draft-koch-librepgp] を参照)

GnuPG 独自の形式 ([[OpenPGP#Standardization|OpenPGP 標準]] から分岐したもの) のほとんどは "バージョン 5" を採用しており (このバージョンは IETF OpenPGP 標準では使用されていません)、非互換性が生じます。

* GnuPG の "バージョン 5" キーは、異なるフィンガープリントを使用します (SHA-256 を使用しているため、より長くなります)
* 新しい対称的に暗号化されたデータパケット形式 ([https://www.ietf.org/archive/id/draft-koch-librepgp-01.html#name-ocb-encrypted-data-packet-t OCB Encrypted Data Packet]))が追加されました。この形式のサポートは、デフォルトで積極的に有効になっている "機能フラグ" によって通知されます。 [[#サポートされていない AEAD メカニズムを無効にする]] を参照してください。
* 新しい [https://www.ietf.org/archive/id/draft-koch-librepgp-01.html#name-post-quantum-cryptography Post-Quantum Cryptography] 形式これも IETF プロセスから分岐したものです ([https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/draft-ietf-openpgp-pqc])

外部レビューでは、GnuPG による形式拡張の健全性について懸念が生じています ([https://blog.pgpkeys.eu/security-issues-librepgp-2024-08.html "A Summary of Known Security Issues in LibrePGP"] を参照)

GnuPG 固有のフォーマット変更に関する懸念事項のより詳細な議論については、[https://blog.pgpkeys.eu/critique-critique.html "A Critique on “A Critique on the OpenPGP Updates”] を参照してください。

Arch Linux の立場は、[[OpenPGP]] 標準との互換性を優先しています。
この目的のために、[https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg/-/blob/1cbbdd291f40d3441b39f5d27c6a3bd4b32ff3c4/gnupg-2.4-revert_default_rfc4880bis.patch デフォルトで RFC4880bis を戻す] などの {{pkg|gnupg}} パッケージにパッチが適用されます。
これにより、他の [[OpenPGP]] 実装との長期的な互換性が保証され、デフォルトでベンダーロックインが回避されます。

== ヒントとテクニック ==

=== サポートされていない AEAD メカニズムを無効にする ===

{{pkg|gnupg}} 2.4 では、[[gpg]] は GnuPG 固有の [[Wikipedia:Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD)|AEAD]] 暗号化メカニズム (OCB に基づく) のサポートを通知するキーを生成します。ただし、AEAD のこのフレーバーは、他の [[OpenPGP]] 実装ではサポートされていません。

多くのダウンストリームは [https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg/-/blob/cfc8f931ee3167a3673b249018dbba527d7428f8/gnupg-2.4-revert_default_rfc4880bis.patch GnuPG ソースにパッチを適用] してこの新しいデフォルトを削除しようとしますが、{{ic|--full-gen-key}} OCB ベースのカスタム AEAD 暗号化メカニズムが新しいキーに設定されています。

GnuPG のカスタム AEAD がキーに設定されているかどうかは、{{ic|gpg}} 自体を使用して検査できます:

$ gpg --expert --edit-key ''<FINGERPRINT>''
gpg> showpref
[ultimate] (1). Foobar McFooface (test) <foobar@mcfooface.com>
Cipher: AES256, AES192, AES, 3DES
AEAD: '''OCB'''
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, '''AEAD''', Keyserver no-modify

このメカニズムは次のように無効にできます:

gpg> setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP
Set preference list to:
Cipher: AES256, AES192, AES, 3DES
AEAD:
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y

=== 他のアルゴリズム ===

強力なアルゴリズムを使用したい場合:

{{hc|~/.gnupg/gpg.conf|
...

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES
}}

GnuPG の最新版では、デフォルトのアルゴリズムとして SHA256 と AES が使われており、どちらも殆どの場合安全です。しかしながら、2.1 以前の古い GnuPG を使っている場合や、さらに高いセキュリティを求めたい場合、上記のように設定するようにしてください。

=== パスワードの暗号化 ===

{{Tip|[[pass]] は以下の作業を自動化します。}}

パスワードを暗号化すれば、設定ファイルに平文で書き込まれなくなります。メールのパスワードなどが良い例でしょう。

まずパスワードを記述したファイルを作成してください。パスワードの後に空行を'''一行'''だけ追加しておく必要があります。そうしないとファイルを評価するときに gpg がエラーメッセージを返します。

そして次を実行:

$ gpg -e -a -r ''<user-id>'' ''your_password_file''

{{ic|-e}} は encrypt、{{ic|-a}} は armor (ASCII 出力)、{{ic|-r}} は受取人のユーザー ID です。

新しく {{ic|''your_password_file''.asc}} ファイルが作られます。

=== 信頼モデルの変更 ===

デフォルトでは GnuPG は信頼モデルとして [[Wikipedia:Web of Trust|Web of Trust]] を使います。Web of Trust から [[Wikipedia:Trust on First|Trust on First]] に変更することが可能です。鍵を追加するときに {{ic|1=--trust-model=tofu}} を追加するか GnuPG の設定ファイルにオプションを追加してください。詳細は [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html GnuPG メーリングリストのメール] を参照。

=== 受取人の id を全て隠す ===

デフォルトでは暗号メッセージには受取人の鍵 ID が含まれます。{{ic|hidden-recipient ''<user-id>''}} を使うことで暗号化するときに ID は削除することが可能です。全ての受取人で ID を削除するには設定ファイルに {{ic|throw-keyids}} を追加してください。この設定によってメッセージの受取人を隠すことができ、トラフィックの解析に対抗することができます (ソーシャルエンジニアリングを使うことでメッセージを復号化できてしまえば誰が受取人なのか確認される可能性があります)。欠点としては、暗号鍵を全て試すことになるので復号化が遅くなります ({{ic|--try-secret-key ''<user-id>''}})。

=== キーサインパーティで caff を使う ===

鍵サーバーやキーリングにある鍵の正当性をユーザーが確認 (つまり鍵の持ち主が本人であることを確認) できるように、PGP/GPG はいわゆる信頼の輪 ("Web of Trust") を利用しています。信頼の輪を維持するために様々なハッカーイベントが開かれており、キーサインパーティはそのひとつです。[[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] 鍵署名プロトコルはキーサインパーティを効果的に行うための方式です。[http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html こちら] にハウツー記事があります。

キーサインパーティの後、鍵に署名したり所有者に署名を送るのを簡略化するために、''caff'' というツールを使うことができます。AUR のパッケージ {{AUR|caff-svn}} でインストールすることができます。

所有者に署名を送信するには [[Wikipedia:ja:メール転送エージェント|MTA]] が必要です。MTA を設定していない場合、[[msmtp]] をインストールして下さい。

=== 長い ID やフィンガープリントを毎回表示する ===

長い鍵 ID を表示させるには設定ファイルに {{ic|keyid-format 0xlong}} を追加してください。鍵の指紋を完全に表示するには、設定ファイルに {{ic|with-fingerprint}} を追加してください。

=== カスタム機能 ===

鍵にカスタム機能を設定することができます。以下の機能を使うことが可能です:

* Certify (マスター鍵のみ) - 副鍵の作成ができるようになります。
* Sign - 公開鍵で検証することができる暗号化署名が作成可能になります。
* Encrypt - 公開鍵でデータを暗号化して、秘密鍵で復号化することができます。
* Authenticate - GnuPG 以外のプログラムで鍵を使って認証できます。SSH 鍵として使用することができるようになります。

マスター鍵の機能は以下のコマンドで指定できます:

$ gpg --full-generate-key --expert

オプションを選択して機能を設定することができます。

副鍵にカスタム機能を指定したい場合、{{ic|gpg --edit-key}} に {{ic|--expert}} フラグを追加してください。詳しくは[[#鍵の編集]]を参照。

== トラブルシューティング ==

=== su ===

{{Ic|pinentry}} を使う場合、使用するターミナルデバイス (例: {{Ic|/dev/tty1}}) の適切なパーミッションが必要です。しかしながら、''su'' (または ''sudo'') を使用すると、所有権は元のユーザーに残り、新しいユーザーにはなくなります。これでは pinentry はたとえ root であっても起動しません。pinentry を使用する (つまりエージェントで gpg を使用する) 前にデバイスのパーミッションを同じ所に変更する必要があります。root で gpg を実行する場合、gpg を使用する直前に所有者を root に変更してください:

# chown root /dev/ttyN # where N is the current tty

そして gpg を使用した後に元に戻して下さい。おそらく {{Ic|/dev/pts/}} と同じのが正しいです。

{{Note|tty の所有者が pinentry を実行しているユーザーと一致している必要があります。{{Ic|tty}} グループに属しているだけでは不十分です。}}

{{Tip|{{ic|script}} で gpg を実行した場合、新しい tty が適切な所有権で使われます:

# script -q -c "gpg --gen-key" /dev/null
}}

=== エージェントがファイルの終末についてエラーを表示する ===

デフォルトの pinentry プログラムは pinentry-gtk-2 であり、D-Bus セッションバスを正しく実行する必要があります。詳しくは[[一般的なトラブルシューティング#セッションのパーミッション]]を見て下さい。

もしくは、{{ic|pinentry-qt}} を使うこともできます。[[#pinentry]] を参照。

=== KGpg 設定のパーミッション ===

{{Pkg|kgpg}} には {{ic|~/.gnupg/}} のオプションが使えないという問題がありました。非推奨となった ''options'' ファイルが原因です。[https://bugs.kde.org/show_bug.cgi?id=290221 バグ] レポートを参照してください。

=== GNOME on Wayland で SSH エージェントのソケットが上書きされる ===

Wayland のセッションでは、{{Ic|gnome-session}} によって {{Ic|SSH_AUTH_SOCK}} が標準の gnome-keyring ソケット {{Ic|$XDG_RUNTIME_DIR/keyring/ssh}} に設定されます。このため {{Ic|~/.pam_environmment}} や systemd のユニットファイルで設定した値が上書きされてしまいます。

この挙動を無効化するには {{Ic|GSM_SKIP_AGENT_WORKAROUND}} 変数を設定してください:

{{hc|~/.pam_environment|2=
SSH_AGENT_PID DEFAULT=
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
GSM_SKIP_SSH_AGENT_WORKAROUND DEFAULT="true"
}}

=== mutt ===

Mutt は ''gpg-agent'' を正しく使用できないため、mutt を使う場合は {{ic|GPG_AGENT_INFO}} [[環境変数]]を設定する必要があります (中身は何でもかまいません)。[[#パスワードのキャッシュ|パスワードのキャッシュ]]も有効化してください。

詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 フォーラムスレッド] を参照してください。

=== gnupg バージョン 2.1 にアップグレードすると鍵が"消失"する ===

{{ic|gpg --list-keys}} を実行しても以前まで使っていた鍵が表示されない場合、また、アプリケーションが鍵を見つけられないまたは鍵が不正だとエラーを吐く場合、鍵が新しいフォーマットに移行できていない可能性があります。

[http://jo-ke.name/wp/?p=111 GnuPG invalid packet workaround] を読んで下さい。要約すると、旧式の {{ic|pubring.gpg}} と {{ic|secring.gpg}} ファイルの鍵にはバグが存在しており、新しい {{ic|pubring.kbx}} ファイルと {{ic|private-keys-v1.d/}} サブディレクトリ、そしてディレクトリのファイルによって置き換えられたということが書かれています。以下のコマンドを実行することで消失した鍵を復旧させることができるかもしれません:

$ cd
$ cp -r .gnupg gnupgOLD
$ gpg --export-ownertrust > otrust.txt
$ gpg --import .gnupg/pubring.gpg
$ gpg --import-ownertrust otrust.txt
$ gpg --list-keys

=== (鍵を受信しようとすると) どの鍵サーバーでも gpg がフリーズする ===

特定の鍵サーバーで鍵を受信しようとして gpg がフリーズしている場合、dirmngr を kill して (問題が起こっていない) 他の鍵サーバーにアクセスできるようにする必要があります。そうしないと全ての鍵サーバーでフリーズしてしまいます。

=== スマートカードが検出されない ===

スマートカードにアクセスするための権限がない場合、カードを正しく設定して接続しても、{{ic|card error}} が表示されることがあります。

スマートカードにアクセスする必要があるユーザーに {{ic|scard}} を追加することで解決できます。追加したら、以下のような [[Udev#udev ルールについて|udev]] ルールを作って下さい:
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki>
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"
</nowiki>}}

VENDOR と MODEL は {{ic|lsusb}} の出力にあわせて変更する必要があります。上記は YubikeyNEO の例です。

=== gpg: WARNING: server 'gpg-agent' is older than us (x < y) ===

{{ic|gnupg}} をアップグレードしたのに古い gpg-agent が動作し続けていると警告が表示されます。ユーザーの {{ic|gpg-agent.socket}} を再起動してください (再起動するときに {{ic|--user}} フラグを使ってください)。

=== IPC 接続の呼び出しに失敗 ===

{{ic|killall gpg-agent dirmngr}} と {{ic|$GNUPGHOME/crls.d/}} フォルダの権限が {{ic|700}} になっていて、{{ic|gpg-agent}} と {{ic|dirmngr}} が起動していないことを確認してください.

デフォルトでは、{{Pkg|gnupg}} パッケージは、ソケットのために {{ic|/run/user/$UID/gnupg/}} ディレクトリを使用します。[https://github.com/gpg/gnupg/blob/25ae80b8eb6e9011049d76440ad7d250c1d02f7c/README#L121-L122 GnuPG documentation] には、このディレクトリが望ましいと書かれています (すべてのファイルシステムがソケットに対応しているわけではありません)。あなたの {{ic|agent-socket}} の設定が、適切なファイルシステムを持つパスを指定しているかどうか確認してください。ic|agent-socket}} のパス設定は、 {{ic|gpgconf --list-dirs agent-socket}} を実行することで確認することができます。

{{ic|gpg-agent}} が正常に起動するか、{{ic|gpg-agent --daemon}} でテストしてください。

=== 汚染された PGP 証明書の軽減 ===

2019 年 6 月、未知の攻撃者が数万(または数十万)の署名を持つ複数の高プロファイル PGP 証明書をスパム送信し(CVE-2019-13050)、これらの署名を SKS 鍵サーバーにアップロードしていました。
これらの汚染された証明書がキーリングに存在すると、gpg は以下のメッセージを表示してハングします。

gpg: removing stale lockfile (created by 7055)

この場合、[https://tech.michaelaltfield.net/2019/07/14/mitigating-poisoned-pgp-certificates/ ブログポスト]にあるように、汚染された証明書を削除することで軽減できる可能性があります。

=== IPC 応答が無効であり、デバイスの ioctl が不適切 ===

デフォルトの pinentry プログラムは、{{ic|/usr/bin/pinentry-gtk-2}} です。{{Pkg|gtk2}} が使用できない場合、pinentry は{{ic|/usr/bin/pinentry-curses}}にフォールバックし、署名に失敗します。

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

pinentry プログラム {{ic|/usr/bin/pinentry-tty}} と {{ic|/usr/bin/pinentry-curses}} を使用するには、環境変数 {{ic|GPG_TTY}} を設定する必要があります。

$ export GPG_TTY=$(tty)

=== キーブロックのリソースが存在しません ===

鍵をインポートしようとしたときに、このようなエラーが発生した場合、

gpg: keyblock resource '''gnupg_home''/pubring.kbx': No such file or directory

これは GnuPG がホームディレクトリを作成しないためです。単に手動で作成してください。

$ mkdir -m 700 ''gnupg_home''

=== サブキーが機能制限されて作成される ===

場合によっては、カスタムの機能セットを使用してサブキーを作成すると、サブキーが "制限付き" としてマークされることがあります。これは、対話型プロンプトで機能が切り替わるときに、オプション 7 または 8 ("set your own capabilities") を指定した {{ic|addkey}} コマンドで発生します。回避策は、機能の選択を求められたときに、個々の機能を切り替えるのではなく、目的の機能セットを文字列として直接入力することです。たとえば、認証機能のみを持つサブキーを作成するには、"=A" と入力します。

== 参照 ==

* [https://gnupg.org/ GNU Privacy Guard ホームページ]
* [https://futureboy.us/pgp.html Alan Eliasen's GPG Tutorial]
* [[RFC:4880|RFC 4880]] — "OpenPGP Message Format"
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]
* [[Fedora:Creating GPG Keys]]
* [[Debian:Subkeys]]
* [https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md Protecting code integrity with PGP]
* [https://sanctum.geek.nz/arabesque/series/gnu-linux-crypto/ A more comprehensive gpg Tutorial]
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]