Tetsuo Handa
from-****@I-lov*****
2009年 12月 21日 (月) 19:41:21 JST
熊猫です。 メモリリークを修正したものを TOMOYO 1.7.1p1 としてアップロードしました。 http://osdn.dl.sourceforge.jp/tomoyo/43375/ccs-patch-1.7.1-20091220.tar.gz MD5: 8888488e0e704c4302480a0af476426c バイナリパッケージを現在作成中です。ファイル名の中に 1.7.1p1 という文字列が 含まれているものが修正済みのカーネルです。 http://sourceforge.jp/projects/tomoyo/releases/?package_id=10270 LiveCD は修正したカーネルで更新済みです。 http://osdn.dl.sourceforge.jp/tomoyo/44679/ubuntu-9.10-desktop-i386-tomoyo-1.7.1p1-20091220.iso MD5: f13e14b24037a66549653bcfe4a95270 http://osdn.dl.sourceforge.jp/tomoyo/44763/CentOS-5.4-i386-TOMOYO-1.7.1p1-20091220.iso MD5: 366789dd3a5c7c98324beebfc34bbaa8 上記の ccs-patch-1.7.1-20091220.tar.gz には 2.6.33-rc1 用のパッチが含まれて います。 TOMOYO 1.x は SELinux や Smack や AppArmor などと共存できるように するために、 struct security_operations *security_ops; を利用しない形で実装 されています。 2.6.33 では TOMOYO が必要とするパス名に関するＬＳＭフックが ほぼ揃ったので、 2.6.33-rc1 用のパッチでは、独自フックの内、ＬＳＭフックでも 実現可能な処理に関してはＬＳＭフックの中に独自フックを埋め込むという方法を 採用しています。 2.6.32.2 用パッチのフック部分 fs/compat.c | 3 ++- fs/compat_ioctl.c | 7 +++++++ fs/exec.c | 3 ++- fs/fcntl.c | 4 ++++ fs/ioctl.c | 5 +++++ fs/namei.c | 38 ++++++++++++++++++++++++++++++++++++++ fs/namespace.c | 22 ++++++++++++++++++++++ fs/open.c | 29 +++++++++++++++++++++++++++++ fs/proc/version.c | 7 +++++++ include/linux/init_task.h | 9 +++++++++ include/linux/sched.h | 6 ++++++ kernel/compat.c | 3 +++ kernel/kexec.c | 3 +++ kernel/kmod.c | 5 +++++ kernel/module.c | 5 +++++ kernel/ptrace.c | 5 +++++ kernel/sched.c | 3 +++ kernel/signal.c | 11 +++++++++++ kernel/sys.c | 11 +++++++++++ kernel/sysctl.c | 4 ++++ kernel/time.c | 5 +++++ kernel/time/ntp.c | 6 ++++++ net/ipv4/inet_connection_sock.c | 3 +++ net/ipv4/inet_hashtables.c | 3 +++ net/ipv4/raw.c | 4 ++++ net/ipv4/udp.c | 7 ++++++- net/ipv6/raw.c | 4 ++++ net/ipv6/udp.c | 4 ++++ net/socket.c | 21 +++++++++++++++++++++ net/unix/af_unix.c | 5 +++++ security/Kconfig | 2 ++ security/Makefile | 3 +++ 32 files changed, 247 insertions(+), 3 deletions(-) 2.6.33-rc1 用パッチのフック部分 fs/compat.c | 2 fs/compat_ioctl.c | 4 fs/exec.c | 2 fs/ioctl.c | 2 fs/namei.c | 10 ++ fs/namespace.c | 9 ++ fs/proc/version.c | 7 + include/linux/init_task.h | 9 ++ include/linux/sched.h | 6 + include/linux/security.h | 60 +++++++++----- kernel/kexec.c | 3 kernel/kmod.c | 5 + kernel/ptrace.c | 4 kernel/sched.c | 2 kernel/signal.c | 10 ++ kernel/sys.c | 10 ++ net/ipv4/inet_connection_sock.c | 2 net/ipv4/inet_hashtables.c | 2 net/ipv4/raw.c | 3 net/ipv4/udp.c | 4 net/ipv6/raw.c | 3 net/ipv6/udp.c | 3 net/socket.c | 5 + security/Kconfig | 2 security/Makefile | 3 security/security.c | 162 +++++++++++++++++++++++++++++++--------- 26 files changed, 274 insertions(+), 60 deletions(-) ＬＳＭのフックは TOMOYO 独自のフックよりも広範囲に挿入されているため、 ＬＳＭのフックの中に TOMOYO 独自のフックを埋め込むことにより、 2.6.32 までは チェックされていなかった箇所で TOMOYO のアクセス許可チェックが行われるように なる場合があります。アプリケーション用のポリシーを作るにあたり、使っている ハードウェアやファイルシステムなどに依存してしまうと、ポリシーを配布することが 不可能になってしまいます。例えば以下のようにスタッカブルファイルシステムを 利用している場合、アプリケーションが要求したパス名だけでなく、下層にある別の ファイルシステム上のパス名に対してもアクセス許可を与える必要が生じて しまいます。 # mkdir /tmp/ro /tmp/rw /tmp/mnt # echo hello > /tmp/ro/file # mount -t aufs -o br:/tmp/rw=rw:/tmp/ro=ro,udba=inotify none /tmp/mnt # cat /tmp/mnt/file TOMOYO 独自のフック（ ccs_open_permission() ）を使った場合は allow_read /tmp/mnt/file だけでＯＫですが、ＬＳＭのフック（ security_dentry_open() ）を使った場合は allow_read /tmp/mnt/file allow_read /tmp/ro/file の両方が必要になります。アプリケーション用のポリシーを作る人が アプリケーションを動かす人の環境のマウント状況まで面倒を見ることはできません。 そのため、アプリケーションからのアクセス要求と、カーネル内部からのアクセス 要求とを区別できるようになっているべきだと考えています。しかし、残念なことに ＬＳＭフックの殆どは区別するための情報が渡されません。ですから、ＬＳＭフックの 中に TOMOYO 独自のフックを埋め込むことは得策とは限らないのです。 実際、ファイルのオープンに関してはＬＳＭフックを使わないようにしています。 それでも、既存のＬＳＭを利用可能な箇所で使っていない実装は門前払いされて しまうようですので、今回、可能な範囲でＬＳＭフックの中に埋め込むようにして みました。どうぞ 2.6.33-rc1 用のパッチをテストしてみてください。問題が 見つかった場合には遠慮なくお知らせください。
TOMOYO
Fork