年越しそばと初詣は絶対に欠かせない

2009年7月16日

Linux でボリュームを暗号化する (1) - swapの保護

Linux のブロックデバイスの暗号化は結構昔から行われている。鍵の管理が貧弱なので、使ってはいなかった。初回に選んだパスワードを未来永劫使うのは、どう考えても高リスクだろう。

諸々の要求に応える為に、Linuxでは LUKS(Linux Unified Key Setup) という珠玉の成果がある。コイツを使えば、パスワードの変更だけでなく、複数のパスワードを持つことも出来るという有り難い代物。

再三設定してるので、ちょっとメモっとかないと、禿げの進行が年2ミリ位早くなってしますので、取り敢えず書いとく。

swapの暗号化

LUKSと言いながら、そうでないものを最初に書くのは何だが、メモリのベタ情報を swap から平文で読まれたくない人は、必ずすべき設定ですね。。。

Debian の cryptsetup 付属の文書 /usr/share/doc/cryptsetup/README.Debian.gz のそのまんまですねぇ。

現在のスワップの無効化

先ず、現在のシステムで /dev/sda2 が swap デバイスとして、swapを無効化し、中身を全消去する(新品で何にも書かれていない場合は、消さなくても構わない)。

# swapoff -a
# shred -n 1 /dev/sda2

設定ファイルを変更する

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-swap /dev/sda2 /dev/random swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
...

/etc/fstab

...
/dev/mapper/crypt-swap none swap sw 0 0
...

暗号化スワップの有効化

# cryptdisks_start crypt-swap
# swapon -a

仮想化環境のゲストOSはメモリ割当が少ない場合が多々あるので、要設定かと思う。

何でも無いが、Linux KVM 上のゲストOSの乱数エントロピーが溜まるの遅くないかぁ。時々、暗号化スワップの開始で４〜５分くらい止まることがときどきある。。。

おやぁ、virtio_rng とか言うモジュールがあるなぁ。。。あるよなぁ。。。コイツが kvm-85 ではまだサポートされていないからなのかぁ。。。KVM に virtio_blk, virtio_net, kvm-clock, virtio_rng の四つ揃えば、準仮想化と変わらんなぁ。。。取り敢えず、待つべし！

2009年7月9日

debian lenny の kvm はバグってる?

以前 Ubuntu に乗り換え宣言したのだが、マイナーなパッケージが無かったり、古いままだったり(まぁコミュニティーベースだから仕方ない)で、Debian lenny に再度乗り換えた。

一番の難点は、、、言わないのが約束だなぁ。

Debian lenny だと kvm-72 がパッケージングされているので、サクサクインストールして使えるのだが、どうも２個以上のゲストOSを立ち上げると何故だか次のメッセージをだしてゲストOSがフリーズしてしまう。

 BUG: soft lockup - CPU#0 stuck for 4096s!

なんすかねぇ？

症状としては、下記のバグ報告と同じっぽい。

BUG: soft lockup - CPU#1 stuck for 4096s! [java:3174] and crash (kvm guest)

で、kvm-84 だと直ってるらしい。。。

ぐふぅ。取り敢えずは、適当に sid からkvm/libvirtのソースパッケージを取ってきてビルドして諸々更新したら、複数のゲストOSがフリーズせずに安定した、、、気がする。

またもや debian squeeze 待ちかなぁ

2009年7月7日

HDDの内容を全部消去する

掃除をしたら多量にPATAのHDDも出てきた。

今まで簡単に特殊なドライバでサクサク開封して磁性体に多量の傷を付けて不燃ゴミにしていた。個人で使っていたもので重要な機密とかが入ってる訳ではないが、少々心もとない。

shred を使って２回の乱数埋めと１回のゼロクリアでHDDの内容を全消去するのが、簡便で良い方法らしい。

# shred -n 3 -z -v /dev/hdb

だが、本当に遅い！

Debian/lenny のバージョンの GNU shred どうも必要な乱数全部を /dev/urandom から読み込むため、乱数生成の帯域で制限されてるっぽい。

『shredのあれこれ』によれば、coreutils-5 では利用する乱数は内部で生成しており、coreutils-6 から /dev/urandom から利用する形になり、６倍遅くなったよという。。。つまり別の乱数発生器の openssl rand を使えと。

で、使ってみたが、、、途中で終ってしまいます。。。

なんでやぁ！！

暫し、熟考の結果 openssl rand の引数は int32_t だったらしく、100Gとかの HDD の消去とかには使えないですなぁ。。。。次のようにすれば完遂できますなぁ

# mkfifo rnd
# while true ; do openssl rand  $((2**31-1)) ; done > rnd &
# shred --random-source=rnd -n 3 -z -v /dev/hdb

大体、上の方法で 300G で 10時間くらい？

ここまではバットノウハウの話。

coreutils の git レポジトリをつらつら流し見たところ。

と言う訳で、coreutils 7.3 からは coreutils-5 の頃の内部乱数(ISAAC)生成が復活し、パス数のデフォルトが 3 pass になるという。

要するに、shred を何も考えずに使った奴が勝者！

それよりも、320G HDD が８台もある敗北者の僕は 100MB/secくらいでるハードウェア乱数生成ボードが欲しい。。。