パスワードを忘れた？ アカウント作成
Close
5523 story

signed_execで実行時にプログラムの身元確認 18

ストーリー by yourCat
導入時のMD5だけでは安心できない人へ 部門より

BSD 曰く、 "Trojanproof.orgがFreeBSD 4.8-Release用のsigned_exec V2を公開している。これは、プログラムのバイナリファイルにあらかじめシグニチャを与えておき、実行時にそれを確認することで不正に置き換えられたプログラムの実行を阻止する仕組みである。カーネルに対するパッチは、FreeBSDとOpenBSDの最近のリリースに対して準備されている。パッチは非公式なものであるため、導入する際はそのことを了承した上で行って欲しい。プレゼンテーション用のpptファイル (Star Office用) が非常に簡潔に分かりやすく機能を説明しているので一読するとよい。
確かにオーバヘッドが増えるが、セキュリティのためには必要な機能なのかもしれないと思う。"

トロイの木馬封じに面白い試みだ。PDFの解説書も用意されている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

signed_execで実行時にプログラムの身元確認 More

  • リンク先の資料をざっと読みました。
    署名、と言う話だけど、コマンド自身のチェックサム結果を内部に埋め込むか、
    システム側に上記のコマンドのチェックサム結果のデータベースを持っていて、
    それを起動直前にチェックして、結果が合致すればコマンドが起動できる、って
    ものみたいですね。

    ＃コマンド単体だと、トロイの木馬が正直にチェックサムつけてたら
    ＃置き換えと起動は防げない、と、資料を読むまでは考えてたんですが、
    ＃システム側で照合するデータを保持するなら、大丈夫ですね。

    ただ、システム側のデータベースに、このセキュリティの強さが依存して
    しまうみたいなので、今度はそっち側をセキュアに守る手法を考えないと
    いけないようですね。
    --
    ---- redbrick
    • reference implementationでは，署名DBはcd9660 fs上に，またはread-onlyなffs上でimmutableフラグをセットしたファイルに置くと書いてありますね．

      PPT資料でも

      Only as secure as the security of the signature database.
      と言ってますし，その辺はちゃんと分かってるみたいです．
      シェア
      親コメント

      • Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)

        by Anonymous Coward on 2003年04月18日 17時25分 (#300907)
        まず最初に、このスレッドの最初からの間違いだけど、署名はチェックサムじゃなくてMD5ですね。

        で、ここからが本題。
        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資料を読み直してみたらちゃんと書いてありました．
          • 攻撃に成功してもrootkitも置けずバイナリも改竄できないような環境では，そもそも攻撃を受けたかどうかが管理者には分からない
          • Honeypotなどでこれを使うと，攻撃を受けた/受けていることが容易に分かるので，他のシステムに対して警告が出せる
          だそうで．
          シェア
          親コメント

          • Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)

            by Anonymous Coward on 2003年04月18日 18時31分 (#300969)
            攻撃をして欲しいのかして欲しくないのか良くわかりませんが(^^;

            ＞至極ごもっとも，と思ってPDF資料を読み直してみたらちゃんと書いてありました．

            • 攻撃に成功してもrootkitも置かずバイナリも改竄しなければ，そもそも攻撃を受けたかどうかが管理者には分からない
            • Honeypotだけセキュリティを上げても無意味だし、他のシステムより先にHoneypotへ攻撃してくれると期待する理由がわからん
            という気がします。
            Honeypotは、クラッカーの生態を観察する:-)とか、クラッカーの身元を特定して逮捕、告発するためには有用ですが、そのためには少しでも長く留まっていてくれた方が良い。
            しかし、こういう仕組みを入れてしまうと、速攻で「おいししくない」と思われて逃げられてしまうので意味が無い。

            「面白そうだ」と思って作ってみたけど、色々穴があったので無理矢理こじつけた「利用価値」という感じがします。

            シェア
            親コメント
        • ＞カーネル中にGPGの公開鍵を持っておいて、バイナリにはバイナリのMD5と、そのMD5へのGPG署名を持つというのはどうでしょう？

          .NET Frameworkの実行時検証がこれと似たような仕組みだったような気がします。あまりちゃんと勉強してないので違ってるかもしれませんが。
          自分の管理するシステム内をどこまで信頼するか、という問題と、アプレットなどのシステム外部のバイナリを信頼するかという問題とを同一視してはいけないのかもしれませんが、PKIの技術でシームレスに世界が広がるという観点からは、サーバよりはクライアントマシンに、もしくは動的なWebサービスとかに生きてくるんだろうか？という感じがします。
          シェア
          親コメント
      • しかし、読み書き不可能なメディアに置いたとしても
        そのディレクトリの参照そのものが、トロイのバイナリの
        チェックサムを置いているディレクトリを参照するように
        書き換えられたら駄目になると思います。

        root権限に何
    • ＃プレビューでは見えたのだけど、題名が長くて切れてました。
      ＃申し訳ない。

      ちなみに、データベースの更新の手間と、(shellやinterpreterの実行)スクリプト
      の更新の手間がトレードオフじゃないと、そういうものにまで適用するのは、
      あまり現実的じゃない気がします。
      ＃手間をかけて守る必要のある部分に限って適用する、という
      ＃方針でもいいのかな？
      ＃管理の都合上、cronとかで自動実行するようなスクリプトは、
      ＃チェック対象にしておいた方がいいんでしょうね。
      --
      ---- redbrick
      シェア
      親コメント
      • あえてスクリプト類にも厳密に適用し、付いてないものには
        制限された実行環境を押し付ける仕組みもありかな
        間違っているものは論外
        また公開鍵で暗号化して特定対象に送り、受けたほうはシグネチャで
        認証後に実行とすれば、あるグループ内での実行ファイルの共有ができ
        使い途が色々考えられるのも確か

  • そのうち (スコア:1)

    by kiyotan (3912) on 2003年04月18日 16時12分 (#300857) 日記
    プログラム１つ動かすにも印鑑証明が必要になりそうですね。
    結局は不特定多数の目に触れる機会のあるものは性悪説に基づいて
    設計するしかないんでしょうかねぇ。そして、そうは設計されて
    ないものは不特定多数の目にさらすことのないようにすると。

    ＃そうするのが本当に最もコストが少ないのかなぁ？
    --
    Kiyotan
  • 実行コードのセキュリティを確保する仕組みができれば
    ネットワークを移動するコードであるモバイルエージェントなどを
    受け入れる素地が広くできあがるのかな？

    # それは楽しみだ

  • NetBSDのveriexec (スコア:0)

    by Anonymous Coward on 2003年04月18日 13時02分 (#300789)
    とはどうちがうのかな。
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー