「ソースコードを元にソフトウェアの異常な動作を検知する侵入検知システム」記事へのコメント

すると攻撃方法は…

[okky (2487)]

まず、当該ソフトを strace で実行して、system call sequence を割り出してから、どこの部分を攻撃するか決め、制御権を奪った後
『どのような順番でシステムコールを発行するべきか』
に従ってシステムコールを発すれば良い、と。

ほぼ全てのソフトが open/close/mmap/read/write を必ず実行する以上、守れる範囲はそんなに広くない気もするが…???
実際問題として、攻撃対象になるようなソフトって大抵 fork/exec もするだろうし…

--
fjの教祖様

Re:

[Anonymous Coward]

でも、面白そうな技術ですよね。

システムコールをトラップするため、利用にはカーネルの修正が必要であるとのことだ。

ここらへんからふと思いついたんだけど、Xenに組み込んだりできないのかな？

予めソースを手に入れて、そのソースを元にモジュールを作って組み込み、という感じからしてSELinuxのような感じになるのかな？

# いや。仕事前の感想にて、失礼

Re:

[okky (2487)]

どちらかというと、こういう技術のためには Ring2 を使えるようにしたほうが良いと思うんだ。Ring3のアプリがいきなり Ring0を呼ぶのではなく、真ん中でいろいろチェックしてくれる Ring1/2層があるkernel…

あぁ、でもそれは Linux では駄目だ。実装できない。
Linus君、micro kernel が大嫌いだったからな

--
fjの教祖様

Re:

[tarosuke (2403)]

移植性を考えたらカーネル全体に影響するような特定プロセッサファミリ固有の機能なんて使いたくないだろうし、microkernelとはあんまり関係ないんじゃないか？

Re:

[okky (2487)]

特権モードがあるプロセッサにおいて、Supervisor モードと user mode の2つしかないプロセッサの方が珍しいと思うが。IA32はもちろん、IA64(風前の灯の Itanium2 の方ね)、Power(PCもそうじゃない方も)、R4000以降は3モード以上あるし。

--
fjの教祖様

Re:

[tarosuke (2403)]

珍しいと言える程マイナーじゃないと思うがな。組み込み向けとか忘れてないか？
移植性を保つには「だいたいの環境で使える」って機能に依存するわけにはいかんだろ。

Re:

[okky (2487)]

組み込み系の大半は User モード自体を持っていませんが。全部 Supervisor。

「どこで何をするのかなど全部事前に判っているのだから、そんな機能はいらん。
  それよりも1個あたりの値段を10円安くしろ」
という声は私自身、直接聞いたこともあります。組み込みの場合、Supervisor mode, MMU, FPUは『いらないから消せ』といわれる3大機能ですな。

つまり、2モードって意外と珍しいって事です。1か、あるいは3以上、はたくさんある。

--
fjの教祖様

Re:すると攻撃方法は…

[tarosuke (2403)]

16bits以下はともかく32bits以上ではあるほうが多い。そういうのは大抵2モードだけどな。

68k系だってSHだってMIPS(R3000以前を故意に無視してない？)だってARMだって大抵2モードじゃないか？何にしてもLinuxは現状では2モードしか使ってないし2モードのプロセッサ用ツリーがある以上、3モード以上を使うようになるとは思えんよ。RING1/2を使うように改造することはできるだろうけど、前にも書いたようにそれをするだけのメリットがあるようには思えないし。

ところで、2つ以上のモードを使うことがセキュリティ的にメリットがあってメジャーなプロセッサでは2モード以上使えるのなら、OpenBSDあたりは当然2モード以上使ってるはずだと思うんだけど、これについてはどう思う？「個人的には実行時に怪しい動作を検出する」などというのは下策であって「そもそも悪さをする方法自体をなくすように設計する」というのが正しいアプローチだと思うけどね。

Re:すると攻撃方法は…

[okky (2487)]

OpenBSDあたりは当然2モード以上使ってるはずだと思うんだけど、これについてはどう思う？

どう思うではなく、根本的に「使うわけ無いじゃん」が答。

モノリシックカーネルデザイン上でセキュリティを構築するなら、2モードだろうね。kernelモード内に存在するものは全て信頼できる、と言うのがモノリシックカーネルの大前提だから。

OpenBSDは「kernel 自身は信じている」という大前提で作られている。kernelが提供する機能を信頼せず、userland に追い出そうとはしておらず、その代わり kernel内部のコードの信頼性を高めるためにレビューを繰り返している。だから、OpenBSDでマルチモードが採択されることは(OpenBSD自身が micro kernel デザインにならない限り)ありえない。

.

マルチモードデザインは、基本的に Mach のように

1) まず全てのリソースを操作できる micro kernel がいて、
2) デバイスドライバーや system call emulator のように micro kernel 上でユーザーのためのサービスを提供するための一連の supervisor process が存在して(つまり、ユーザー空間を必要に応じてアクセスできる特権者としてのプロセスがいて)
3) supervisor process の提供するサービスを利用する user process がいる

時に初めて役に立つ。2のレベルと3のレベルが「別物でなくてはいけない」かつ2のレベルは3のレベルを自由に制御できなくてはいけない(1まで戻らないと制御できないのでは、2で提供できるはずの機能を1に盛り込まなくてはいけないから)というスタンスに立った場合に初めて意味が出てくる。

現実問題として、このような制御方式はマルチプロセッサ(マルチコアでもいいが)が当たり前にならないと全然性能が出ない。だから、今までは無かった。それだけの話。

--
fjの教祖様