タイトルにはすべてが書かれていますが、もう少し詳しく説明します。
キーリングパスワードが私のキーをどのように保護しているか疑問に思っています。確かに、それはコンテナファイルを暗号化するので、他の誰もそれにアクセスすることはできません。ただし、キーリングパスワードを入力した後も復号化されます。したがって、実際には、ログインしているときに、悪意のあるアプリによってキーが盗まれる可能性があります(少なくとも、root権限を持つアプリは盗むことができるはずです)。
もちろん、パスワードを入力した後、キーファイル自体は復号化されたバージョンに置き換えられませんが、メモリ内で復号化する必要があります。
問題は、悪意のあるアプリが復号化中にキーリングのデータにアクセスできるかどうかです。もしそうなら、私のディスクがすでに暗号化されていて、私だけが私のコンピューターを使用しているときに、キーリングのパスワードさえ必要ですか?
また、パスワードの安全性が高い場合、ログイン後にアカウントのパスワードなどを使用して、パスワードのロックを自動的に解除することはできますか?
(私はログインマネージャーを使用していません。TTY経由でログインした後、i3wmを自動的に起動します。したがって、このセットアップでも自動ロック解除は可能ですか?)
悪意のあるアプリは、復号化中にキーリングのデータにアクセスできますか?
実際には(現在)、はい、できます。 Linuxのユーザーセッションの現在の設計(またはその欠如)により、gnome-keyring-daemonがどのプログラムがそれにアクセスしようとしているのかを判断することが困難になっています。これは、コンパイルされたプログラムに対してある程度実行可能ですが、たとえば、 Pythonで記述されたアプリは、Pythonで記述された他のアプリと区別がつきません。したがって、gnome-keyringには最初はアプリケーションのホワイトリストがありましたが、現在のバージョンにはありません。
最終的には、SnapやFlatpakなどのアプリコンテナプロジェクトによってこれを改善する必要があります。
もしそうなら、私のディスクがすでに暗号化されていて、私だけが私のコンピューターを使用しているときに、キーリングのパスワードも必要ですか?
はいと思います。
上記のように、どのプログラムもD-Busメッセージを送信し、gnome-keyring-daemonに秘密を要求することができます。 (場合によっては、機能としても機能します。)
ただし、脆弱なプログラム(Webブラウザなど)を使用してファイルを盗む可能性があるセキュリティホールがかなりありますが、コマンドを実行したりD-Busメッセージを送信したりする可能性はありません。 。マルウェアは、暗号化されていないSSHキー(~/.ssh/id_rsa
)またはビットコインコアウォレットを盗むことが知られています。
同様に、暗号化されていない場合は、~/.local/share/keyrings/login.keyring
がWebブラウザのエクスプロイトなどによって盗まれる危険性があります。
(私はログインマネージャーを使用していません。TTY経由でログインした後、i3wmを自動的に起動します。したがって、このセットアップでも自動ロック解除は可能ですか?)
Gnome-keyringの自動ロック解除は、すべての場合にPAMを介して行われます。 pam_gnome_keyring.so
という名前のモジュールは、ログインプロセスの一部としてパスワードを受け取り、最初のキーリングデーモンを起動します。
PAMモジュールは、Linuxディストリビューションが通常共通モジュールを追加する場合は常に/etc/pam.d
に追加するか、login
ファイル(特にコンソールおよびTelnetログイン用)に追加する必要があります。
Authグループ(Debianスタイルのcommon-auth
の「Additional」ブロック;それ以外の場合は最後のモジュールとして)で、パスワードをメモリに保存します。
[...]
auth optional pam_gnome_keyring.so only_if=login
セッショングループ(ここでも、Debianの「追加」ブロック、それ以外の場合は最後のモジュール)で、保存されているパスワードを使用して開始しますgnome-keyring-daemon:
[...]
session optional pam_gnome_keyring.so only_if=login auto_start