2011年07月13日
ext4 secure delete
ext4のSecure Deleteについて紹介します。
2011/7/13現在(linux-3.0-rc7)、
まだメーリングリスト上で議論中なのでメインラインへはマージされていません。
この機能はext4の拡張属性に"s"を追加(chattr +s)して、
それが設定されているファイルを削除するときは、
カーネル空間では0でデータをクリアしてあげましょうというものです。
なぜそんなことをしているかというとext4はデータを削除するときにメタデータだけを
クリアしており、実物のデータはそのままであるためです。
なので、うまいことハッキングすれば削除したはずのデータが読み出せてしまいます。
データを削除するときにメタデータだけを更新するほうがデータ量が少なくて
パフォーマンスが良いです。
つまり、この機能はトレードオフでセキュリティを重視したいファイルなどだけに設定し、
実際の削除が遅くなるのは目をつぶるという感じです。
下記のパッチがリリースされています。
EXT4: Secure Delete: Zero out files directory entry
0/2 [PATCH 0/2 v3] EXT4: Secure Delete
http://www.spinics.net/lists/linux-ext4/msg26365.html
1/2 [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data
http://www.spinics.net/lists/linux-ext4/msg26364.html
inodeにEXT4_SECRM_FLが設定されていた場合、
カーネル内部のフラグEXT4_FREE_BLOCKS_ZEROを設定し、
ブロック解放処理でそのフラグの有無を判定し対象となるブロックに0で書き込みます。
EXT4_FREE_BLOCKS_ZEROが設定されていない場合は、通常のブロック開放(メタデータのみ更新)を
行います。
2/2 [PATCH 2/2 v3] EXT4: Secure Delete: Zero out files directory entry
http://www.spinics.net/lists/linux-ext4/msg26366.html
2つ目はディレクトリエントリに対する0うめ処理部です。
inodeに EXT4_SECRM_FLが設定されていた場合、
ディレクトリエントリに内部のflag EXT4_DEL_ENTRY_ZEROを設定します。
EXT4_DEL_ENTRY_ZEROが設定されていたら
dnetryのnameを0でうめ、そのdentryを保持するblockをディスクへ書き出します。
flagが設定されていない場合は従来のディレクトリエントリの削除処理をします。
ここで0クリアするのはnameとfile_typeのみです。
ディレクトリエントリの構造体は下記のとおりなのですが、
このパッチではinode番号を消してないのですが、別にいいのだろうか。
dentry2構造体ごと0うめすればいいと思うけど、もしかしたらI/Oの発行を抑えるために重要そうな
エントリだけけしているのかもしれない。
struct ext4_dir_entry_2 {
__le32 inode; /* Inode number */
__le16 rec_len; /* Directory entry length */
__u8 name_len; /* Name length */
__u8 file_type;
char name[EXT4_NAME_LEN]; /* File name */
};
まだ議論中なのですが、方向性に問題はなさそうなので近いうちに実装されるでしょう。
他のファイルシステムの実装はよくわからないのだけれど、ext以外はすでにこのような
データ消し方はできているのだろうか。
とりあえず、パーソナルユースではこの機能にお世話になることはなさそうです。
2011/7/13現在(linux-3.0-rc7)、
まだメーリングリスト上で議論中なのでメインラインへはマージされていません。
この機能はext4の拡張属性に"s"を追加(chattr +s)して、
それが設定されているファイルを削除するときは、
カーネル空間では0でデータをクリアしてあげましょうというものです。
なぜそんなことをしているかというとext4はデータを削除するときにメタデータだけを
クリアしており、実物のデータはそのままであるためです。
なので、うまいことハッキングすれば削除したはずのデータが読み出せてしまいます。
データを削除するときにメタデータだけを更新するほうがデータ量が少なくて
パフォーマンスが良いです。
つまり、この機能はトレードオフでセキュリティを重視したいファイルなどだけに設定し、
実際の削除が遅くなるのは目をつぶるという感じです。
下記のパッチがリリースされています。
EXT4: Secure Delete: Zero out files directory entry
0/2 [PATCH 0/2 v3] EXT4: Secure Delete
http://www.spinics.net/lists/linux-ext4/msg26365.html
1/2 [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data
http://www.spinics.net/lists/linux-ext4/msg26364.html
inodeにEXT4_SECRM_FLが設定されていた場合、
カーネル内部のフラグEXT4_FREE_BLOCKS_ZEROを設定し、
ブロック解放処理でそのフラグの有無を判定し対象となるブロックに0で書き込みます。
EXT4_FREE_BLOCKS_ZEROが設定されていない場合は、通常のブロック開放(メタデータのみ更新)を
行います。
2/2 [PATCH 2/2 v3] EXT4: Secure Delete: Zero out files directory entry
http://www.spinics.net/lists/linux-ext4/msg26366.html
2つ目はディレクトリエントリに対する0うめ処理部です。
inodeに EXT4_SECRM_FLが設定されていた場合、
ディレクトリエントリに内部のflag EXT4_DEL_ENTRY_ZEROを設定します。
EXT4_DEL_ENTRY_ZEROが設定されていたら
dnetryのnameを0でうめ、そのdentryを保持するblockをディスクへ書き出します。
flagが設定されていない場合は従来のディレクトリエントリの削除処理をします。
ここで0クリアするのはnameとfile_typeのみです。
ディレクトリエントリの構造体は下記のとおりなのですが、
このパッチではinode番号を消してないのですが、別にいいのだろうか。
dentry2構造体ごと0うめすればいいと思うけど、もしかしたらI/Oの発行を抑えるために重要そうな
エントリだけけしているのかもしれない。
struct ext4_dir_entry_2 {
__le32 inode; /* Inode number */
__le16 rec_len; /* Directory entry length */
__u8 name_len; /* Name length */
__u8 file_type;
char name[EXT4_NAME_LEN]; /* File name */
};
まだ議論中なのですが、方向性に問題はなさそうなので近いうちに実装されるでしょう。
他のファイルシステムの実装はよくわからないのだけれど、ext以外はすでにこのような
データ消し方はできているのだろうか。
とりあえず、パーソナルユースではこの機能にお世話になることはなさそうです。
【Linuxの最新記事】
この記事へのコメント