web-dev-qa-db-ja.com

ブートパーティションのキーファイルでLUKS暗号化Debianルートのロックを解除します

ブートパーティション（復号化されたパーティション）に格納されているキーファイルを使用して、Debianルートを復号化しようとしています。これはセキュリティを壊しますが、今は問題ではありません。私はこれを首尾よく結論付けなければならないか、試して死ぬ必要があります。

initramfsへのフックを作成しました。キーファイルは/bootファイル内のinitrd.img-*ディレクトリにあります。キーファイル（/boot/keyfile）へのパスは/etc/crypttabファイルにあります。

initramfsをSudo update-initramfs -uで更新しましたが、次のメッセージを受け取りました：cryptsetup: WARNING: target sdaX_crypt uses a key file, skipped.

メッセージを無視して再起動すると、ディスクが起動できなくなります。メッセージGave up waiting for root device.が表示され、initramfsシェルにドロップされます。

initramfs環境にはcryptsetupは存在しません。 （存在する必要がありますか？）

update-initramfs -uはsdaX_cryptデバイスが別の方法でマウントされ、keyfileで復号化するように構成されていないことを「考え」ているようです。

どうすればよいですか？

debianluksinitramfscryptsetup
6
Fusgyus

代わりに、crypttabでkeyscriptオプションを使用できます（man crypttab）。パスフレーズをエコーするスクリプトを作成し、それをkeyscript引数として設定して、ramfsを再生成するだけです。フックは必要なく、スクリプトを/ boot /に置く必要もありません。

vg1-root_crypt UUID=94a3b301-123-12-a3-ea0403 none luks,keyscript=/etc/echo-root-luks-pass

Cryptsetupのinitramfsフックがなぜcrypttabにキーファイルをリストすることを禁止しているのか、私にはわかりません。おそらくそのような振る舞いを容赦したくないでしょう。

追伸私はそれがセキュリティを壊すとは思わない、それはあなたの/ bootパーティションがどれだけ安全であるかに応じて多少それを弱めるだけです。たとえば、USBドライブから/ bootをオフにして、靴下などにUSBを入れておきます。

4
spinkus

メッセージを本当に無視し、パーティションをスキップしないようにするには、（少なくとも）コメントアウト/削除する必要がありますreturn 1 in /usr/share/initramfs-tools/hooks/cryptrootエラーメッセージが書き込まれる行の後（274行目付近-使用されているcryptsetupバージョンに依存）。このファイルはデフォルトではパッケージマネージャーによって管理されているため、cryptsetupパッケージの更新時に上書きされることに注意してください。

問題の詳細については https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776409 も参照してください。

私はそれをテストしていませんが、キーファイルのケースが考慮されない理由は、上記以外にも考えられます。

3
jofel

Debianのcryptsetup docsによると、/etc/cryptsetup-initramfs/conf-hookで定義されたシェルスタイル（グロビング）パターンKEYFILE_PATTERNに一致するキーファイルはinitramfsに含まれますが、他のキーファイルは含まれません。

  • Debian 9の場合：/usr/share/doc/cryptsetup/README.{initramfs,Debian}.gz
  • Debian 10の場合：/usr/share/doc/cryptsetup{-initramfs/README.initramfs,-run/README.Debian}.gz。

以前のバージョンのDebianについてはわかりません。

これらのファイルはzless filename.gzで読み取ることができますが、ここでは、便宜上および将来の参照のために、関連する部分を示します。

12.キーファイルをinitrdに直接保存する

通常、キーファイルを使用するデバイスは無視され（大きな警告が表示されます）、キーファイル自体はinitrdに含まれません。これは、initramfsイメージが通常、暗号化されていない/ bootパーティションに存在するためです。ただし、キーファイルをinitrdに含めることが望ましい場合もあります。たとえば、GRUBの最近のバージョンは、暗号化されたブロックデバイスからの起動をサポートし、暗号化された/ bootパーティションを許可します。

Crypttab（5）にリストされているキーファイルのうち、環境変数KEYFILE_PATTERN（シェルパターンとして解釈される）の値に一致するファイルは、initramfsイメージに含まれます。たとえば、/ etc/crypttabに2つのキーファイル/etc/keys/{root,swap}.keyがリストされている場合、以下を/ etc/cryptsetup-initramfs/conf-hookに追加して、initrdに追加できます。

KEYFILE_PATTERN = "/ etc/keys/*。key"

さらに、initramfsイメージに秘密鍵マテリアルを含める場合は、非特権ユーザーを寄せ付けないようにするために、制限付きのumaskでイメージを作成する必要があります。これは、以下を/etc/initramfs-tools/initramfs.confに追加することで実現できます。

UMASK = 0077

1
ignis

私のメモリがうまく機能している場合、暗号化されていないパーティションからブートしたので（update-initrdを実行しているときに）fstabが暗号化されていないボリュームを指しているため、fstabが暗号化されたパーティションを指すように変更されていることが問題です。 initrdイメージを作成した後、fstabを変更して暗号化されたパーティションを指すようにすることができます。

1
YoMismo

@ignisの2番目の答えですが、これを機能させるには、次のように/etc/crypttabファイルにinitramfsオプションが必要です。

# <target name> <source device>             <key file>          <options>
mapper-name     /etc/disk/by-id/scsi_xxxxx  /etc/keys/luks.key  luks,initramfs

Obs：私は答えについてコメントしたでしょうが、まだ十分な評判がありません。

0
chromator