web-dev-qa-db-ja.com

パスフレーズを要求せずにLUKSパーティションがマウントされるのはなぜですか？

私のシステムには、2つの暗号化されたディスクがあります。

  1. ラズビアンストレッチのルートパーティションを含むクリプト
  2. usb-cryptは外部USBディスクです。そのディスクではLVMが使用されます。

両方のディスクは同じパスフレーズを使用して保護されていますが、マスターキーは「cryptsetupluksDump」によって異なります。 2つのディスクはどちらもキーファイルを使用して構成されていません（LUKSコンテナーごとに1つのキースロットのみが使用されます）。

システムが起動しているとき、「crypt」のパスフレーズを要求していますが、usb-cryptはパスフレーズを要求せずに自動的にマウントされます。注：暗号化されていないルートパーティションから始めましたが、そのセットアップで、起動時にusb-cryptのパスフレーズを要求されました。

詳細な設定は次のとおりです。

$ Sudo dmsetup ls --target crypt
crypt   (254, 0)
usb-crypt       (254, 1)

$ Sudo cat /etc/fstab
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mapper/crypt  /            ext4    defaults,noatime  0       1
# ...
UUID=b9fb061f-0877-4d2c-bd3c-9c155b8f88a5       /mountpoint       ext4            rw,auto                 0       0

$ Sudo cat /etc/crypttab 
# <target name> <source device>         <key file>      <options>
crypt   /dev/mmcblk0p2  none    luks
usb-crypt       UUID=31fb8df7-6148-4408-90a2-93b8ec752fa0       none    luks

パスフレーズを1回入力するだけで便利ですが、この動作に驚いています。私は両方のパスフレーズを求められると思っていました。

これは、両方のディスクで同じパスフレーズを使用することに関連していますか？または、usbディスクのマスターキーは、「crypt」の暗号化されたルートパーティションのどこかに自動的に保存されますか？誰かがここで何が起こっているのかを説明し、関連するログファイルなどにヒントを与えることができれば幸いです。

前もって感謝します！

raspbianlukscryptsetup
6
wiede

あなたのパスワードを尋ねるinitスクリプトがそれを使って何をしているかに依存します。

systemdの場合、それは単なる機能である可能性があります。 _systemd-ask-password_には、責任があるかもしれないキャッシュ機能が付属しています。

https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html

_--accept-cached

    If passed, accept cached passwords, i.e. passwords previously entered.

--multiple

    When used in conjunction with --accept-cached accept multiple passwords.
    This will output one password per line.
_

この方法では、最初に既に入力したパスワードを試し、それが機能しない場合にのみ別のパスワードを要求します。

このようなアイデアの欠点は、LUKSではパスワードのチェックに1秒のCPU時間がかかるため、LUKSコンテナーが多数ある場合、これらの試行によって速度が低下する可能性があることです。しかし、ほとんどの人は1つか2つしか持っておらず、実際には同じパスフレーズを使用することも珍しくありません。

実際にこれに責任があるソースコードを見つけることができなかったので、上記は推測にすぎず、これが何らかの方法で無効にすることを選択できる機能であるかどうかはわかりません。

責任のあるコードと思われるものを見つけました Githubでここを参照 。

_tries = 0_で始まり、反復ごとにtriesをインクリメントするforループがあります。

このループは、_bool accept_cached_の場合に_tries == 0 && !arg_verify_をtrueに設定してget_password()を呼び出します。したがって、ループの最初の反復でキャッシュされたパスワードがすでにある場合は、キャッシュされたパスワードを返すだけです。これらが機能しない場合は、_tries == 1_を使用した次の反復で_accept_cached_をfalseに設定し、その場合のみ、試行する別のパスフレーズを提供するように求めます。

パスワードのリストはattach_luks_or_plain()に渡されます。これは、最初の反復で以前にキャッシュされたパスワードであり、後続のすべてのパスワードで単一の新しいパスワードになるため、以前に試行されたパスワードを再試行しません（おそらく同じパスワードを入力し続ける場合を除く）。

パスワードをプレーンテキストでメモリに保持することに関しては、パスワードのリストは__cleanup_strv_free_erase_ char **passwords = NULL;_として宣言されているため、少なくとも、ある時点でクリーンアップが適切に処理されるように聞こえます。

キーは常にメモリ内のどこかにあり、多くのことは助けることができません。cryptが機能するためにはマスターキーが必要です。コンテナが開いている限り、常に_dmsetup table --showkeys_で確認できます。

通常、有効なパスフレーズを入力するのは_arg_tries = 3_ 3回試行されているようですが、複数のコンテナがあり、キャッシュされたパスワードが機能しなかった場合、キャッシュされたパスワードは2回しか入力できません。試みはすでに最初の試みとして数えられます。これが本当かどうかをテストするための暗号化されたsystemdマシンがないか、どこかでコードを読み間違えているだけです。

6
frostschutz