アカウント名:
パスワード:
PPT資料でも
Only as secure as the security of the signature database.
で、ここからが本題。 CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね? だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・ CDだと最初の一度目の実行には多少時間かかるかもしれませんが、それはDB参照する時も一緒だし、2度目からは(RAMさえ潤沢にあれば)ディスクキャッシュが効きます。 何らかのバグでディスクキャッシ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
起動前binaryチェックサム作成とチェックサム確認用デ (スコア:2, 参考になる)
署名、と言う話だけど、コマンド自身のチェックサム結果を内部に埋め込むか、
システム側に上記のコマンドのチェックサム結果のデータベースを持っていて、
それを起動直前にチェックして、結果が合致すればコマンドが起動できる、って
ものみたいですね。
#コマンド単体だと、トロイの木馬が正直にチェックサムつけてたら
#置き
---- redbrick
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:2, 参考になる)
PPT資料でも
と言ってますし,その辺はちゃんと分かってるみたいです.Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)
で、ここからが本題。
CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね?
だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・
CDだと最初の一度目の実行には多少時間かかるかもしれませんが、それはDB参照する時も一緒だし、2度目からは(RAMさえ潤沢にあれば)ディスクキャッシュが効きます。
何らかのバグでディスクキャッシ
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1)
.NET Frameworkの実行時検証がこれと似たような仕組みだったような気がします。あまりちゃんと勉強してないので違ってるかもしれませんが。
自分の管理するシステム内をどこまで信頼するか、という問題と、アプレットなどのシステム外部のバイナリを信頼するかという問題とを同一視してはいけないのかもしれませんが、PKIの技術でシームレスに世界が広がるという観点からは、サーバよりはクライアントマシンに、もしくは動的なWebサービスとかに生きてくるんだろうか?という感じがします。