アカウント名:
パスワード:
PPT資料でも
Only as secure as the security of the signature database.
で、ここからが本題。 CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね? だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・ CDだと最初の一度目の実行には多少時間かかるかもしれませんが、それはDB参照する時も一緒だし、2度目からは(RAMさえ潤沢にあれば)ディスクキャッシュが効きます。 何らかのバグでディスクキャッシュが汚染されるとダメだけど、それはこの署名DBをCDに置いた場合でも同じ。 チェックサム検証にかかる時間分だけ早くて済みそう。
immutableフラグにしても、署名DBにimmutableフラグが付いてれば信用できるというのであれば、バイナリにimmutableフラグを付ければ済むような・・・
と、ケチばかり付けててもアレなので(^^;別解。 カーネル中にGPGの公開鍵を持っておいて、バイナリにはバイナリのMD5と、そのMD5へのGPG署名を持つというのはどうでしょう? これだと信頼できるバイナリ提供者からのバイナリはそのまま使えますし、自分でバイナリ作る場合はあらかじめ自分のGPG公開鍵を含んだカーネルを作っておけばOK。 もちろんカーネル自体を入れ替えられてしまうとダメですが、そこまで言ったらこのsigned_execでも同じ事だし・・・
CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね? だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・
>至極ごもっとも,と思ってPDF資料を読み直してみたらちゃんと書いてありました.
「面白そうだ」と思って作ってみたけど、色々穴があったので無理矢理こじつけた「利用価値」という感じがします。
root権限に何らかの方法で昇格し、仮想デバイスを作成、 マウントし、そこに偽造DBをロードして CDROMへの参照をそこに参照するように書き換えたら後は何で出来るようになるのでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
起動前binaryチェックサム作成とチェックサム確認用デ (スコア:2, 参考になる)
署名、と言う話だけど、コマンド自身のチェックサム結果を内部に埋め込むか、
システム側に上記のコマンドのチェックサム結果のデータベースを持っていて、
それを起動直前にチェックして、結果が合致すればコマンドが起動できる、って
ものみたいですね。
#コマンド単体だと、トロイの木馬が正直にチェックサムつけてたら
#置き
---- redbrick
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:2, 参考になる)
PPT資料でも
と言ってますし,その辺はちゃんと分かってるみたいです.Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)
で、ここからが本題。
CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね?
だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・
CDだと最初の一度目の実行には多少時間かかるかもしれませんが、それはDB参照する時も一緒だし、2度目からは(RAMさえ潤沢にあれば)ディスクキャッシュが効きます。
何らかのバグでディスクキャッシュが汚染されるとダメだけど、それはこの署名DBをCDに置いた場合でも同じ。
チェックサム検証にかかる時間分だけ早くて済みそう。
immutableフラグにしても、署名DBにimmutableフラグが付いてれば信用できるというのであれば、バイナリにimmutableフラグを付ければ済むような・・・
と、ケチばかり付けててもアレなので(^^;別解。
カーネル中にGPGの公開鍵を持っておいて、バイナリにはバイナリのMD5と、そのMD5へのGPG署名を持つというのはどうでしょう?
これだと信頼できるバイナリ提供者からのバイナリはそのまま使えますし、自分でバイナリ作る場合はあらかじめ自分のGPG公開鍵を含んだカーネルを作っておけばOK。
もちろんカーネル自体を入れ替えられてしまうとダメですが、そこまで言ったらこのsigned_execでも同じ事だし・・・
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1)
- 攻撃に成功してもrootkitも置けずバイナリも改竄できないような環境では,そもそも攻撃を受けたかどうかが管理者には分からない
- Honeypotなどでこれを使うと,攻撃を受けた/受けていることが容易に分かるので,他のシステムに対して警告が出せる
だそうで.Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)
>至極ごもっとも,と思ってPDF資料を読み直してみたらちゃんと書いてありました.
- 攻撃に成功してもrootkitも置かずバイナリも改竄しなければ,そもそも攻撃を受けたかどうかが管理者には分からない
- Honeypotだけセキュリティを上げても無意味だし、他のシステムより先にHoneypotへ攻撃してくれると期待する理由がわからん
という気がします。Honeypotは、クラッカーの生態を観察する:-)とか、クラッカーの身元を特定して逮捕、告発するためには有用ですが、そのためには少しでも長く留まっていてくれた方が良い。
しかし、こういう仕組みを入れてしまうと、速攻で「おいししくない」と思われて逃げられてしまうので意味が無い。
「面白そうだ」と思って作ってみたけど、色々穴があったので無理矢理こじつけた「利用価値」という感じがします。
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1)
.NET Frameworkの実行時検証がこれと似たような仕組みだったような気がします。あまりちゃんと勉強してないので違ってるかもしれませんが。
自分の管理するシステム内をどこまで信頼するか、という問題と、アプレットなどのシステム外部のバイナリを信頼するかという問題とを同一視してはいけないのかもしれませんが、PKIの技術でシームレスに世界が広がるという観点からは、サーバよりはクライアントマシンに、もしくは動的なWebサービスとかに生きてくるんだろうか?という感じがします。
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:0)
そのディレクトリの参照そのものが、トロイのバイナリの
チェックサムを置いているディレクトリを参照するように
書き換えられたら駄目になると思います。
root権限に何
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1)
あとはsecurelevelを上げておけば,raw deviceを叩いてfs直接書き換えとか,immutable flagを落とすとかいった攻撃方法も回避できますね.この実装でもsecurelevelによって署名のチェックをするかどうか決めているようですし.
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:0)
今回の仕組みはトロイの木馬からroot権限その他を守ることが目的でしょうし。
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:0)