| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
AKARI 1.0.27 以前をカーネル 2.6.28 以前（ RHEL 4/5 などが該当）で使用している場合、ある種のプログラムを実行した後にカーネルパニックが発生するという不具合が見つかりました。この問題は悪意が無くとも発生するので、攻撃される心配のない安全な環境で解析用途で使用している場合であっても、アップデートするようにしてください。
http://sourceforge.jp/projects/tomoyo/lists/archive/users/2012-October/000975.html
「社長が現れて無限ループから救い出してくれた」でこちらへ来られた方へ：元ネタを知りたい場合は AQUA 第１巻の第４話 「猫の王国」をご覧ください。・・・最初は頭の中でぐるぐる回るほうの無限ループかと思って、まぁ社長が悩めるアリスちゃんを救う話ってどんなんだったっけ？と考えてしまいました。（笑）
ということで（？）本文。
カーネル 2.6.23 以前および 2.6.30 以降において、一部のインタプリタ（例えば /lib/ld-linux.so.2 ）のパーミッションがチェックされていなかったのを修正しました。
TOMOYO 2.x および AKARI では全てのインタプリタのパーミッションが security_bprm_check() でチェックされているものと思っていました。しかし、実際には open_exec() を呼び出すハンドラの内、一部しか search_binary_handler() を呼び出していませんでした。そのため、 security_bprm_check() ではなく security_dentry_open() でインタプリタのパーミッションをチェックしてやらないと漏れが発生することが判明しました。
TOMOYO および AKARI では、プログラムの実行（ execve() ）要求に対しては execute 権限を、インタプリタや共有ライブラリなどの利用（ open() ）要求に対しては read 権限をチェックするという、普通とは違う判断基準を採用しています。
例えばシェルの場合、「バイナリプログラムとしての /bin/bash の execute 権限をチェックしておこう」という主張は納得できます。しかし、「 /bin/bash が必要とする共有ライブラリはプログラムとして解釈されるのだから共有ライブラリに対しても execute 権限をチェックしておこう」という主張には納得できません。その主張を認めるのなら「シェルに入力される文字列はプログラムとして解釈されるのだから標準入力である /dev/tty に対しても execute 権限をチェックしておこう」「シェルから読み込まれる設定ファイルに含まれる文字列はプログラムとして解釈されるのだから ~/.bashrc に対しても execute 権限をチェックしておこう」という調子で、全てのファイルの execute 権限をチェックすることになるでしょう。つまり、 execute 権限をチェックする価値が消滅してしまうと思うのです。プログラムとして実行されるかどうかはファイルを読み込むプログラムの内容に依存しているため、プログラムとして実行されるかどうかをカーネル側で判断する術はありません。そのため、カーネル側に於いて、プログラムとして解釈される共有ライブラリについては execute 権限をチェックするけれども、プログラムとして解釈される標準入力や設定ファイルについては execute 権限をチェックしないというのは、不釣り合いに思えるのです。
そこで、 TOMOYO および AKARI ではプログラムの実行要求に渡されたパス名を読み込みモードでオープンする場合には execute 権限を、それ以外に渡されたパス名を読み込みモードでオープンする場合には read 権限をチェックするようになっています。前者は呼び出し側が制御権を譲渡するという明確な意思表示であるのに対し、後者はそうではないからです。
さらに、 TOMOYO および AKARI では要求された側のプログラムが必要とするインタプリタや共有ライブラリのパーミッションは、プログラムの実行（ execve() ）を要求した側ではなく、要求された側の権限でチェックされています。これは、インタプリタや共有ライブラリが必要になるのは（要求する側の事情ではなく）要求される側の事情であるから、要求される側でチェックを行うほうが自然であるという考え方に基づいています。しかし、カーネル 2.6.29 以降、プログラムの制御権が譲渡されることが確定するまでは要求された側の権限で動作することが許されなくなってしまったので、 search_binary_handler() でのチェックは可能でも security_dentry_open() でのチェックは不可能なのです。
このような普通とは異なる処理を行うために、 TOMOYO 1.x および AKARI ではプロセス単位の変数を用いて状態を管理しています。しかし、 TOMOYO 2.x ではプロセス単位の変数を用いる許可をまだ貰えていません。そのため、現時点では TOMOYO 1.x や AKARI と同じ解決策を使えません。
さてさて、どうやってこの問題を解決しようか・・・頭の中で無限ループ？
カーネル 2.6.29 以降において「プログラムの実行（ execve() ）を伴わないドメイン遷移の結果が子プロセスに継承されない」という制限事項を解消しました。
「生クリームのせプリン」でこちらへ来られた方へ：元ネタを知りたい場合は AQUA 第２巻の Special Navigation 「風邪とプリン」をご覧ください。熊猫の場合は寝不足な日々が続いていたのが原因だったようで、風邪薬のお世話にならずに済みました。
久しぶりにスラドへ行ってみたら、 過労死 Linux なんていう恐ろしいものを見つけました。・・・で、スレッドを読んでいたら「アクア・アルタ」が登場したので、灯里ちゃんを連想してしまいました。（笑）
カーネル 2.6.37-rc1 への対応を追加しました。
Unix ドメインソケットのパス名の取り扱い間違いを修正しました。
いやはや、 Unix ドメインソケットは取り扱いが難しいですなぁ。設定系の操作では struct sockaddr_un と同じ大きさのバッファを渡せばＯＫなのに、取得系の操作ではそれよりも１バイト大きなバッファを渡してやらないとアドレスが切り詰められてしまう場合がある（つまり sun_path[0] != '\0' でも printf("%s", sun_path); のようにするとオーバーランする危険がある）だなんて、 man ページには書かれてないものなぁ。
それから、 AKARI ちゃんが火星に来てくれたおかげ（違）で、 TOMOYO ちゃんにも大きな変化が訪れました。TOMOYO の T は task_struct の T な訳ですが、２００３年からずっと task_struct に埋め込んでいた変数を外部のハッシュテーブルに移動させるという選択肢が増えました。この選択肢を利用することにより、ディストリビュータが作成したカーネルパッケージとＡＢＩ互換の TOMOYO カーネルパッケージを作ることができるようになり、 TOMOYO カーネルパッケージに含まれていないカーネルモジュールを再コンパイルしないで済むようになる・・・筈です。
さてさて、１１／１１の TOMOYO 1.8 リリースに向けて、ユーザランドの整備を急がないと・・・。
アクセスログなどに含まれているタイムスタンプを UNIX time 形式から YYYY/MM/DD hh:mm:ss 形式に変更しました。
getattr() 操作と open(O_DIRECTORY) 操作もアクセス解析／制限の対象になりました。
umount() 時に自動的に / が付加されてしまうことで、ファイルのアンマウントがディレクトリのアンマウントのように見えてしまう不具合を修正しました。
x86_32 だけでなく x86_64 でも動作することを確認しました。
accept() 操作もアクセス解析／制限の対象になりました。（ただし、ソケットを accept() した直後に呼ばれるＬＳＭフックが存在しないため、実際にアクセス解析／制限されるのは accept() したソケットに対して何らかの操作（データの送受信など）を行ったタイミングになります。）
Off-by-two バグにより Unix ドメインソケットのパス名の末尾にゴミが付いてしまう不具合を修正しました。
ネーミングは ARIA the Animation / ARIA the Natural / ARIA the Origination というアニメに登場する水無灯里からです。 ARIA はＴＶ放映時に ARIA the Natural の最終話を観たことしかなく、当時は話の内容を全然理解できませんでした。しかし、今年６月、 YouTube で ARIA 全話を観て、カードキャプターさくらの世界の再来とでも言いましょうか、優しくて幸せな気持ちを味わえる作品であることを知りました。アニメを気に入ったので、原作を買って読んだ上で、今回は ARIA の登場キャラの中から選ぼうと決めました。
「 TOMOYO はアクセスを制限することでセキュリティを高める道具であるから、安全なＬＡＮ環境にある開発マシンに導入しても意味が無い」と誤解されているという仮定の下、「 TOMOYO の自動学習機能を用いてアクセス要求を記録することにより開発環境用のデバッグツールとしても利用できる」ことを知ってもらうために AKARI プロジェクトを始めました。
そのため、最初はアクセス要求を記録する機能だけを実装して ARIA ( Access Requests Instant Accumulator ) という名前で公開しようと考えていました。しかし、公開のために sourceforge.jp にプロジェクトを作ろうとして「 Linux ARIA 」で検索してみたところ、既に国産ダウンローダソフトの名前として ARIA というのが使われていたことが判明。また、ソースコード的にも TOMOYO のソースコードからポリシー違反が発生してもエラーを返さないようにするだけという、何とも中途半端で存在意義不明な実装になっていたため、「やっぱりアクセスを制限する機能は残しておこう」と決めました。
そして、実装内容と実装方法について決まったので、 sourceforge.jp のプロジェクト名を考えることになりました。
まぁ社長に噛みつかれて「ぷいにゅ〜」な ARIA 社長を候補から外すとなると、当たり前だったものをキラキラ輝かせてみせる「摩訶不思議」な AKARI ちゃん、「あらあら、うふふ」と言いつつ全てお見通しな ALICIA さん、「〜〜禁止」を連発する AIKA ちゃん、「でっかい自分ルール」な ALICE ちゃん、「すわっ」を連発する AKIRA さん、陰で助けてくれる「気配り名人」な ATHENA さん、妖術を使う「神出鬼没」な Cait Sith さんが候補として挙がりました。
検討の結果、「アクセス要求内容（ Access ）の保存（ Keep ）と制限（ Regulate ）を行う道具（ Instrument ）である」「ローダブルカーネルモジュールなのでどんな環境でもすんなりと溶け込んでいける」「ブラックボックスなシステム内部の動作に光を当てることができる」などの理由から AKARI ( Access Keeping And Regulating Instrument ) になりました。「 Linux AKARI 」で検索したところ、 sourceforge.net には同名のプロジェクトが存在していましたが、もはや活動していないので混乱することはないだろうと考え、 AKARI という名前で申請しました。
スラドにはTUBASAを期待している人がいましたが、 Tokyo までは楽しめる作品だったのに、 Tokyo 以後は読むのが辛い作品になってしまったので、遠慮させていただきました。
AKARI は Linux 2.6 カーネル向けのアクセス解析／制限モジュールです。 TOMOYO Linux の作者である熊猫さくらが個人で勝手に開発して公開しているものであり、ＮＴＴデータとして承認されたものではありませんのでご注意ください。
TOMOYO Linux を使うのに、 TOMOYO 1.x は機能は多いけれどカーネル本体を置き換えなければいけないので敷居が高い、 TOMOYO 2.x はディストリビュータがサポートしてくれていれば簡単に導入できるけれども RHEL では SELinux しかサポートされていないのでやっぱり敷居が高い、という問題がありました。
Linux カーネル 2.6 のＬＳＭ（ Linux Security Modules ）はＬＫＭ（ Loadable Kernel Modules ）からはアクセスできないと信じられてきましたが、実際にはＬＫＭからＬＳＭへアクセスするため抜け道が存在しています。
そこで、 AKARI ではこの抜け道を使うことで、 TOMOYO 1.x の機能をなるべく維持しながらＬＫＭとして追加可能なＬＳＭモジュールとして作成することにより、ディストリビュータがサポートしてくれなくても簡単に導入できるようにすることを目指しています。ＬＳＭが有効になっているカーネル 2.6.3 〜 2.6.36 を搭載したディストリビューションで使えます。
２０１０年１０月１０日に初版をリリースしました。
http://sourceforge.jp/projects/tomoyo/lists/archive/users/2010-October/000768.html
http://sourceforge.jp/projects/tomoyo/lists/archive/users-en/2010-October/000219.html