Tetsuo Handa
from-****@I-lov*****
2010年 7月 15日 (木) 12:11:55 JST
TOMOYO
Fork 熊猫です。
＃ AppArmor 来ましたね。いよいよ入るのかな？
KaiGai Kohei さんは書きました：
> 例えば、あるドメインから
> /proc/sys/kernel/core_pattern が read-only で
> procfs:/sys/kernel/core_pattern が read-writable というポリシーがあった場合、
>
> これはどういった動作をするべきでしょう？ :(
>
> procfs がどこにマウントされているかは、実行時にしか分からないので、
> 事前に弾くというのは難しいかもしれませんが…。
この提案は、 procfs 上の sys/kernel/core_pattern というファイルには
（ procfs がどこにマウントされていようとも） proc:/sys/kernel/core_pattern
というパス名でアクセスできるようにしようというものです。ですから、この提案を
採用した場合、今まで /proc/sys/kernel/core_pattern というパス名に対して
与えていたアクセス許可は proc:/sys/kernel/core_pattern というパス名に対して
与えるようになります。 /proc/sys/kernel/core_pattern というパス名が与えられた
場合、（ ext3 などの）rename 操作をサポートするファイルシステム上のファイルで
あると解釈されるようになります。
> > rename 操作をサポートするファイルシステム上のファイルに対するパス名の表記は
> > 従来のままです。
> >
> rename 操作がサポートされていると何かマズイ事でもあるんでしたっけ？
>
> 例えば『ext3で/dev/sda1(major=8, minor=3)をマウントしている区画』を
>
> /home/kaigai/.ssh => ext3(8,3):kaigai/.ssh
>
> こんな感じで書けてもあまり違和感は感じませぬが…。
> （で、none区画の場合 '('...')' を省略すれば上記と同じですね）
>
rename をサポートしているファイルシステム上にあるファイルはプログラムや
データファイルなど、（ Windows の場合でも）パス名を open に渡すことにより
アクセスされる情報を含んでいると考えます。それに対し、 rename をサポートして
いないファイルシステム上にあるファイルはプロセスのメモリイメージやシステムの
情報など、（ Windows の場合には）パス名を open に渡すのではなく他の関数を
使うことによりアクセスされる情報を含んでいると考えます。（例えば Windows では
バージョン情報を取得するのに open("/proc/version", O_RDONLY) という方法ではなく
GetVersionEx() という方法を使います。）
この提案は、「 open() という方法でアクセスされるデータ」と「 GetVersionEx() の
ように open() 以外の方法でアクセスされるデータ」とを区別し、後者にはマウント
ポイント（ Windows の場合はドライブ名）に依存しないアクセス手段を提供します。
で、何故 rename をサポートするファイルシステムでは絶対パス名を使うかというと、
(1) rename は open で指定するパス名を変更させるものである。
rename をサポートするファイルシステムではパス名が変わることがある。
(2) アプリケーションにとっては、 / からの絶対パス名が意味を持つ。
あるマウントポイント以下の etc/shadow というパス名が存在しても、
アプリケーションが必要とするのは / パーティションにある etc/shadow であり、
例えば /var/ パーティションに存在している etc/shadow は必要としない。
つまり、 /var/ パーティション内の etc/shadow が rename されても
アプリケーションに影響は無いが、 / パーティション内の etc/shadow が
rename されると影響を受ける。そのため、 ext3:etc/shadow とか
dev(8,1):etc/shadow という指定では、どのパーティションにある etc/shadow
なのかを特定できないため、アプリケーションにとって意味のある指定ができない。
/etc/shadow とか /var/etc/shadow のように / からの絶対パス名で指定して初めて
アプリケーションにとって意味のある指定が可能になる。
(3) パス名が変わるとアクセスの可否や使われ方や振る舞いが変化するので、パス名の
変化を最小限に抑える必要がある。（ただし、ラベルであってもパス名の変化により
使われ方や振る舞いが変化するので、パス名の変化を最小限に抑える必要があるのは
同じである。）使われ方や振る舞いに影響を与えるか否かを考える際に
アプリケーションにとって意味のあるパス名である / からのパス名が必要になる。
からです。
> > です。１つ心配なのは、 rename 操作をサポートしないけれどもプログラムの
> > execute 操作はサポートするというファイルシステムが存在しないかどうかです。
> > そのようなファイルシステムの場合、（ TOMOYO Linux のドメイン名に含まれる
> > パス名は / で始まる必要があるので） TOMOYO Linux はドメイン遷移を行えなく
> > なってしまいます。そんなファイルシステムは存在しないとは思いますが・・・。
> >
> プログラムの execute 時に proc:/path/to/executable をマクロ展開でもするように、
> /proc/path/to/executable に変換して、それをプログラムのドメインに変換してみては
> いかがでしょう？
> （内部データ形式上難しかったりします？）
aggregator の存在を忘れていました。（＾＾；
aggregator proc:/path/to/executable //procfs/path/to/executable みたいに指定
すれば allow_execute proc:/path/to/executable ではなく
allow_execute //procfs/path/to/executable となるので対処できますね。
でも、それ以前に、 procfs 上の「 プロセスＩＤ/exe 」というシンボリックリンクを
execve() に渡すという可能性がありましたね。現状でも allow_execute /proc/self/exe
とか allow_execute /proc/\$/exe とかいうアクセス許可が必要になるケースが存在
しているということですね。 allow_execute にはワイルドカードを認めていないので、
aggregator /proc/\$/exe //procfs/running/program という指定により
allow_execute //procfs/running/program というアクセス許可に変換することになる
わけですが、現在動作中の任意のプログラム（ /bin/bash とか /usr/bin/python ）の
実行を認めるという意味になるので、 if exec.realpath= という条件節も付けて
制限してやらないと危険ですね。