KaiGai Kohei
kaiga****@ak*****
2010年 7月 15日 (木) 09:54:58 JST
TOMOYO
Fork海外です
(2010/07/13 22:28), Tetsuo Handa wrote:
> 熊猫です。
>
> procfs が /proc/ 以外の場所にマウントされることがあり得るので、 TOMOYO 2.x では、
> /proc/PID/ を経由してプロセスに関する情報に対するアクセス許可を与える場合に
> 自プロセスの情報にだけアクセスを認めるような指定ができません。
> そのため、 procfs が /proc/ 以外の場所にマウントされた場合でも
> 自プロセスの情報にだけアクセスを認めるような指定ができるようにするために、
> procfs （などの rename 操作をサポートしないファイルシステム）上のファイルに
> 対するパス名の表記を、従来の / からの絶対パス名からファイルシステム内の
> 絶対パス名に変更しようかと考えています。
>
> 現在の表記 新しい表記
>
> /dev/pts/0 => devpts:/0
> /proc/tty/driver/serial => proc:/tty/driver/serial
> /sys/kernel/security/tomoyo/domain_policy => securityfs:/tomoyo/domain_policy
> /sys/power/state => sysfs:/power/state
>
> rename 操作をサポートするファイルシステム上のファイルに対するパス名の表記は
> 従来のままです。
>
rename 操作がサポートされていると何かマズイ事でもあるんでしたっけ？
例えば『ext3で/dev/sda1(major=8, minor=3)をマウントしている区画』を
/home/kaigai/.ssh => ext3(8,3):kaigai/.ssh
こんな感じで書けてもあまり違和感は感じませぬが…。
（で、none区画の場合 '('...')' を省略すれば上記と同じですね）
> この変更による利点は
>
> (1) proc:/self/status のように指定すれば自プロセスの情報にだけアクセスを
> 認めることができるようになり、 proc:/\$/status のように指定すれば他
> プロセスの情報へのアクセスを認めることができるようになる。 SELinux に
> おける区別の粒度には及ばないが、 TOMOYO 1.x と同じ粒度での指定ができる
> ようになる。
>
> (2) 当該ファイルシステム上の特定のファイルへのアクセスだけを認めることが
> できるようになる。（ SELinux では procfs 上の多くのファイルに proc_t
> という同じラベルを割り当てているのに対して）パス名１個を単位とした指定が
> 可能になるため、 SELinux における区別の粒度よりも細かく指定できる。
>
ちなみに、SELinux は procfs 上のラベル付けを、genfscon というルールを使って、
procfs のルート基点の絶対パスで表現します。
↓こんな感じ
genfscon proc /sys/kernel/modprobe system_u:object_r:sysctl_modprobe_t:s0
> (3) /proc/ とか /proc2/ とか /p/ とか /tmp/foo/100/p/ のように procfs が
> 何処にマウントされていても proc:/ というパス名で指定できるようになる。
>
> です。１つ心配なのは、 rename 操作をサポートしないけれどもプログラムの
> execute 操作はサポートするというファイルシステムが存在しないかどうかです。
> そのようなファイルシステムの場合、（ TOMOYO Linux のドメイン名に含まれる
> パス名は / で始まる必要があるので） TOMOYO Linux はドメイン遷移を行えなく
> なってしまいます。そんなファイルシステムは存在しないとは思いますが・・・。
>
プログラムの execute 時に proc:/path/to/executable をマクロ展開でもするように、
/proc/path/to/executable に変換して、それをプログラムのドメインに変換してみては
いかがでしょう？
（内部データ形式上難しかったりします？）
> もし、この変更を試したい場合
> http://marc.info/?l=linux-fsdevel&m=127884477806888&w=2 にあるパッチを
> http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=snapshot;h=4a8ece22b1e2309a76b8af0787b636dee5e85209;sf=tgz からダウンロードできる
> スナップショットに適用する（TOMOYO 2.x）か、
> http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-patch/?root=tomoyo と
> http://sourceforge.jp/projects/tomoyo/svn/view/trunk/1.7.x/ccs-patch/patches/?root=tomoyo にあるパッチと
> http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/?root=tomoyo にあるツールを
> 使う（TOMOYO 1.x）ことができます。
>
> 質問や意見はありませんか？
>
例えば、あるドメインから
/proc/sys/kernel/core_pattern が read-only で
procfs:/sys/kernel/core_pattern が read-writable というポリシーがあった場合、
これはどういった動作をするべきでしょう？ :(
procfs がどこにマウントされているかは、実行時にしか分からないので、
事前に弾くというのは難しいかもしれませんが…。
では
--
KaiGai Kohei <kaiga****@ak*****>