12月版　ネットワークアクセス権も放棄せよ

小崎資広
2010/1/12

　新年明けましておめでとうございます。皆さまいかがお過ごしでしょうか？ 筆者はうっかり昨年末にパッチをLKMLに送ってしまったのがたたって、まったく心の休まらない正月でした、しくしく。そういえば、去年もTOMOYOのパッチをレビューして正月をつぶしたんだよなぁ……なんて思い出がよみがえります。

　さてさて、去年はTOMOYO、perf/trace、KSM、discardとさまざまなパッチがマージされましたが、今年はいったいどんなパッチが登場するのでしょうか？

disablenetworkから始まった議論、LSMに飛び火

　Michael Stoneは、disablenetworkという新しいセキュリティ機構を投稿しました。disablenetworkとは、DJB（qmail、djbdnsの作者として有名。またセキュリティに対して独特のこだわりがあることが広く知られています）が提唱している、新しいタイプのセキュリティ機構（注1）です。

　実行中のプロセスは、setuidによって指定したUID（ユーザーID）の権限に移行できますが、このときexploit（注2）リスク低減のため、自発的に特権を放棄するテクニックが広く使われています。同じように、「ネットワークアクセス権」についても自発的に放棄できるようにしよう、というのがdisablenetworkの基本アイデアです。

　従来は、ネットワークアプリケーションがセキュリティホールを突かれて乗っ取られてしまうと、（SELinuxなどの機構により）システム自体は十分堅牢に守られていても、踏み台として別のマシンの攻撃に使われてしまうというリスクがありました。

　disablenetworkはprctl(PR_NETWORK_OFF)を呼び出すことにより動作を開始し、それ以降、新規ネットワークコネクションを張ることを拒否します。prctl()呼び出し以前に張ってあるコネクションはそのまま使えるため、事前に通信相手のIPアドレスなどが特定できない汎用ネットワークアプリケーションにも適用できます。

　意図としては、システムで広範囲に使われているライブラリに脆弱（ぜいじゃく）性が存在した場合、アプリケーション開発者の努力だけではexploitを防ぐのに限界があるため、OS側で支援しようということのようです。背景には、数年前に見つかったzlibの脆弱性などが念頭にあるのでしょう。これは一見、なかなか理にかなった仕組みに見えます。

　しかしPavel Machekは、たとえdisablenetworkがあっても、suidプログラムと組み合わせることにより、DoS攻撃が成立可能であると指摘しました。disablenetworkされたプロセスからsuidプログラムを起動することにより、意図的にネットワークシステムコールを失敗させることができます。これを繰り返すことにより、rootユーザーにCPU時間を100％使い尽くさせることが可能だというのです。

　Michaelは、この機能はビルド時にON／OFFを切り替えることができるオプショナルな機能であることを基に反論しましたが、Pavelは「CONFIG_ADD_SECURITY_HOLEはbad ideaだよ」とそれを制します。

　Serge E. Hallynは、「capabilityにCAP_NETWORK_REENABLEというフラグを作って、suidプログラムが再度ネットワークをenableできるようにしたらどうか」と提案しました。しかしEric W. Biedermanは、「いやいや、suidプログラムを好きに暴れ回らせるような修正は解決になっていないから、現在マウントオプションになっているMNT_NOSUIDをスレッドフラグに拡張し、disablenetworkされたプロセスはsuidプログラムを実行しても権限の昇格が起こらないようにするべきだ」と、新しい関数、prctl()の追加を提案しました。またAndrew G. Morganは、「おいおい、suid周りの動作を変えるなら、prctlでハックしないでsecurebits（注3）を使いなよ」といい出し、議論は一気に迷走の度を深めます。

　ここでラスボスとしてAlan Cox登場。LSM Hookを使っていないことを理由に、disablenetworkに対し否定的な見解を示します。「セキュリティの概念は幅広いので、毎年新しいセキュリティ機構が提案されているのが現状だが、そのたびにコアコードを変えていたらメンテナンスできなくなってしまうのではないか」というわけです。また、そのためにLSMがあるんだから、それを使うべきだとも。

　もちろんMichaelは、LSMの存在を知らないわけではありません。しかし、現状のLSMにはセキュリティモジュールを1つしか有効（enable）にできないという制限があるため、今回のようなSELinuxと組み合わせて使いたいマイクロセキュリティモジュールにはうまくフィットしないのです。Alan Coxはそれに対して、「複数のモジュールをenableできるよう、LSMをスタッカブルにすればいいだけだろう？ 例えば、

lsm_context = (struct my_lsm_context *)(task->security + lsm->offset)

というコードを追加したとしても、オーバーヘッドは1クロックかそこらだろう」と諭します。ここで議論はLSMのスタッカブル化へと飛び、一気に話が大きくなります。

　実はこの話は、過去に何度も議論されてきました。そしてそのたびに「ただでさえSELinuxは複雑過ぎるぐらいなんだから、スタッカブルにしたら誰にも理解できなくなってしまう」という理由で却下されてきたようです。

　Tetsuo Handaは、SELinux＋TOMOYOはメインラインにマージされていない独自配布版で十分な実績があるので、スタッカブルを許可できるようにしたいと要望しましたが、議論の参加者のほぼ全員から、ことごとく否定的な見解を受け取ります。やはり、コンビネーションはマイクロセキュリティモジュールに限定したいという気持ちが強いようです。

　この議論は正月休みの真っ最中に行われたため、結論は若干拡散してしまいましたが、参加者からは前向きなレスポンスが大半だったので、disablenetworkは近い将来のマージが期待できそうです。

注1：http://cr.yp.to/unix/disablenetwork.html 注2：セキュリティホールを悪用した攻撃コードのこと。パッチがないのに出回ることもあります 注3：rootになったときでも、特権を得られないようにする機能のこと。2008年7月版で少し紹介しています。

関連記事：
	スイッチ・オン！ SELinux（＠IT Security&Trust）
	知られざるセキュリティフレームワーク「LSM」の役割

11月版へ

1/2

Index Linux Kernel Watch　12月版 　ネットワークアクセス権も放棄せよ

Page 1 　disablenetworkから始まった議論、LSMに飛び火 　 Page 2 　2.6.33マージウィンドウで見掛けた粋なパッチたち

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）