[tomoyo-users 846] Re: WARNING メッセージの種類

Back to archive index

Tetsuo Handa from-****@I-lov*****
2011年 5月 27日 (金) 21:50:45 JST


早間義博 さんは書きました:
> ダイナミックライブラリの機能がわかっていないので、変な表現になって
> しまいました。
> perlを使用した監視プログラムをいくつも動かしています。実行中にライ
> ブラリが変更された場合が心配だったのです。
> 的外れだったのかな、と思っています。firefox などは更新すると動作が
> おかしくなることがあります。
> 

ライブラリファイルのパス名の変化があれば捕捉してくれるので、心配いらないと
思います。

> # openoffice の更新などはかなりの時間がかかります。

emerge するドメインにはアクセス制御を適用しない方が良いと思います。

> # gentoo では update で 50くらいのライブラリ・コマンドが1度に更新が
> # 発生することがあります。中に openoffice がある場合は非力なマシンだ
> # と1日がかりです。

−−−−−−−−−−−−−−−−−−−−

> /lib/\*.so などは回避出来ますが、
> perl などは
> lrwxrwxrwx 1 root root    10  4月 27 19:43 /usr/bin/perl -> perl5.12.3
> -rwxr-xr-x 1 root root  5400  4月 27 19:41 /usr/bin/perl5.12.3
> となっています。
> TOMOYO に基本理念に反するかも知れませんが、link を突き詰めることを
> やめる設定は無理でしょうか。

#↑ link というと hard link のことを指すので、 symlink または soft link と
#呼んでくださいね。

allow_execute に関してはシンボリックリンク解決前のパス名でパーミッション
チェックを行うようになっています。それ以外に関してはシンボリックリンク解決後の
パス名でパーミッションチェックを行うようになっています。

前者をシンボリックリンク解決後のパス名を使うようにすることは可能ですが、
後者をシンボリックリンク解決前のパス名を使うようにすることは不可能です。
というのも、ユーザランドから渡されたパス名は、カーネル内部での名前解決処理
(シンボリックリンクや /../ や /./ などを解決する処理)を経て、最終的に
struct dentry と struct vfsmount という2つの構造体に変換されます。名前解決が
終わった後に呼ばれる LSM フックがこの struct dentry と struct vfsmount を
受け取り、 TOMOYO を利用している場合には struct dentry と struct vfsmount から
パス名を逆算します。しかし、この struct dentry と struct vfsmount は既に
シンボリックリンクを解決した後のパス名を指しているため、シンボリックリンクを
解決する前のパス名を計算するには手遅れなのです。

# allow_execute に関してシンボリックリンク解決前のパス名を利用できているのは、
# LSM フックから execve() に渡されたパス名の情報にアクセスできるためです。

> <kernel>  /usr/bin/kterm /usr/bin/perl
> 
> で止まっていれば perl の更新も怖くありません。
> 自分で perl などを更新するユーザだけが危険を冒せば良いのです。

ドメイン名については allow_execute で指定されたパス名を利用しており、
allow_execute ではシンボリックリンク解決前のパス名を用いているため、
<kernel> /usr/bin/kterm /usr/bin/perl5.12.3 のようなドメイン名にはならないと
思うのですが?

−−−−−−−−−−−−−−−−−−−−

> > ccs-tools 1.8 の ccs-editpolicy に関して、例外ポリシーで指定されている
> > acl_group のアクセス許可も o キーの対象にするように修正しました。( ccs-tools
> > 1.7 および tomoyo-tools 2.3 の例外ポリシーの allow_read には未対応です。)

今日、 ccs-tools 1.7 および tomoyo-tools 2.3 の方も対応させました。
対応させながら、柔軟な制御が行えるようになった ccs-tools 1.8 の ccs-auditd や
ccs-patternize を TOMOYO 1.7 や TOMOYO 2.3 でも使えるようにバックポートしたい
という誘惑に駆られました。 Gentoo 的には問題ないのでしょうが、 Ubuntu や
Debian 的にはバグフィックスとして認めてもらえる範囲を超えてしまって問題に
なりそうなので悩んでいます。




tomoyo-users メーリングリストの案内
Back to archive index