Tetsuo Handa
from-****@I-lov*****
2011年 5月 24日 (火) 14:30:38 JST
早間義博 さんは書きました: > tomoyo が出力するログは > TOMOYO-ERROR: > TOMOYO-WARNING: > WARNING: > の3種類だけでしょうか。 printk(KERN_INFO "TOMOYO Linux initialized\n"); printk(KERN_WARNING "ERROR: Out of memory at %s.\n", function); printk(KERN_WARNING "%s ( %s ) is not permitted to " "update policies.\n", domainname->name, exe); printk(KERN_ERR "You need to define profile %u before using it.\n", profile); printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ " "for more information.\n"); printk(KERN_ERR "You need to install userland programs for " "TOMOYO 2.3 and initialize policy configuration.\n"); printk(KERN_INFO "TOMOYO: 2.3.0\n"); printk(KERN_INFO "Mandatory Access Control activated.\n"); printk(KERN_WARNING "%s: Access %s denied for %s\n", r->mode == TOMOYO_CONFIG_ENFORCING ? "ERROR" : "WARNING", buffer, tomoyo_last_word(domain->domainname->name)); printk(KERN_WARNING "TOMOYO-WARNING: " "Domain '%s' has so many ACLs to hold. " "Stopped learning mode.\n", domain->domainname->name); printk(KERN_INFO "Not activating Mandatory Access Control now " "since %s doesn't exist.\n", tomoyo_loader); printk(KERN_INFO "Calling %s to load policy. Please wait.\n", tomoyo_loader); printk(KERN_WARNING "TOMOYO-ERROR: Domain '%s' not defined.\n", tmp); panic("Failure registering TOMOYO Linux"); panic("MAC Initialization failed.\n"); panic("Can't register tomoyo_kernel_domain"); panic("Profile %u (used by '%s') not defined.\n", profile, domain->domainname->name); panic("Profile version %u is not supported.\n", tomoyo_profile_version); −−−−−−−−−−−−−−−−−−−− > また、tomoyo-editpolicy で > allow_umount /eml > が追加できません、 紛らわしいのですが、 TOMOYO 2.3 ではプロファイルでの指定は file::umount なのに 対してドメインポリシーでの指定は allow_unmount です。 TOMOYO 1.8 では プロファイルでの指定は file::unmount なのに対してドメインポリシーでの指定は file unmount です。 それから、 /eml はディレクトリなので、 /eml/ のように指定する必要があります。 −−−−−−−−−−−−−−−−−−−− > また、前掲の xterm に対する learning mode を再開させるにはどのよう > にすれば良いのでしょう。 まず http://tomoyo.sourceforge.jp/2.3/chapter-5.html#5.6 をお読みください。 その上で、 echo 'PREFERENCE::learning={ max_entry=4096 }' | tomoyo-loadpolicy -p のように実行してください。また、 ( echo 'select <kernel> /usr/bin/afterstep /bin/sh /usr/bin/xterm'; echo 'delete quota_exceeded' ) | tomoyo-loadpolicy -d のように実行すると、再度 max_entry に到達した場合に TOMOYO-WARNING: が 表示されます。 なお、次のブロックの内容を先に理解して、 前掲の xterm (これは <kernel> /usr/bin/afterstep /bin/sh /usr/bin/xterm ドメインで動作しているほうです)の learning mode を再開させたいのか それとも、 ポリシーエディタで示されている xterm (これは <kernel> /usr/bin/xterm ドメイン で動作しているほうです)の learning mode を再開させたいのか を考えた上で行ってください。 −−−−−−−−−−−−−−−−−−−− > ポリシに定義されていない usb メモリを mount umount しても追加もさ > れませんし、ERROR にもなりません。 最も怪しいのは、 /bin/mount や /bin/umount を実行している /usr/bin/xterm の ドメインが意図したドメインではないという可能性ですね。前のブロックの操作を 行うことで <kernel> /usr/bin/afterstep /bin/sh /usr/bin/xterm ドメインの学習は 再開されますが、再開前に既に 2048 個のアクセス許可が与えられている筈です。 しかし、ポリシーエディタのドメインは <kernel> /usr/bin/xterm ドメインであり、 まだ55個しかアクセス許可が与えられていません。 > keep_domain <kernel> /usr/bin/afterstep /bin/bash /usr/bin/xterm > keep_domain <kernel> /usr/bin/afterstep /bin/sh /usr/bin/xterm > initialize_domain /usr/bin/xterm 上記のような指定だと、 /usr/bin/xterm を実行した場合 <kernel> /usr/bin/xterm ドメインへと遷移してしまうため、 <kernel> /usr/bin/afterstep /bin/bash /usr/bin/xterm ドメインや <kernel> /usr/bin/afterstep /bin/sh /usr/bin/xterm ドメインへ到達することは できなくなります。(ただし、 initialize_domain /usr/bin/xterm を追加する前に 起動された /usr/bin/xterm のプロセスは <kernel> /usr/bin/xterm ドメインへは 遷移しないため、前掲のように <kernel> /usr/bin/afterstep /bin/sh /usr/bin/xterm ドメインで動作し続けます。) /usr/bin/xterm から cat /sys/kernel/security/tomoyo/self_domain を実行して どのドメインに所属しているのかを確認してください。 −−−−−−−−−−−−−−−−−−−− > <kernel> /usr/bin/xterm > 0: allow_read/write /\* > 2: allow_read/write /\{\*\}/\* 例外ポリシーで path_group ANY_PATHNAME /\* path_group ANY_PATHNAME /\{\*\}/\* のように定義して、ドメインポリシーから allow_read/write @ANY_PATHNAME のように参照するようにもできますよ。 TOMOYO 1.8 の場合、デフォルトで path_group ANY_PATHNAME / path_group ANY_PATHNAME /\* path_group ANY_PATHNAME /\{\*\}/ path_group ANY_PATHNAME /\{\*\}/\* path_group ANY_PATHNAME \*:/ path_group ANY_PATHNAME \*:/\* path_group ANY_PATHNAME \*:/\{\*\}/ path_group ANY_PATHNAME \*:/\{\*\}/\* path_group ANY_PATHNAME \*:[\$] path_group ANY_DIRECTORY / path_group ANY_DIRECTORY /\{\*\}/ path_group ANY_DIRECTORY \*:/ path_group ANY_DIRECTORY \*:/\{\*\}/ number_group COMMON_IOCTL_CMDS 0x5401 acl_group 0 file ioctl @ANY_PATHNAME @COMMON_IOCTL_CMDS acl_group 0 file read @ANY_DIRECTORY acl_group 0 file getattr @ANY_PATHNAME という指定が行われるようになっており、ディレクトリの参照と全てのパス名に対する stat と 0x5401 番の ioctl を暗黙のうちに許可しています。 −−−−−−−−−−−−−−−−−−−− > 今まで気にもしていなかったことですが、 > allow_ioctl /usr/bin/xxxx 0x5401 > などと許可を与えることになると何を許可したのか不安になります。 > (socket も同様です) > 0x5401 などの意味するところについてわかりやすい(e.g. 一覧表) > などはどこかに無いものでしょうか、 この数値の解釈はその機能を提供しているサブシステム次第であり、 DACパーミッションでいうところの「ビット0が execute 、ビット1が write 、 ビット2が read 」のような約束事は存在しません。興味があれば http://thread.gmane.org/gmane.linux.kernel.lsm/12543 のスレッドを参照ください。 よく見かける 0x5401 についてはカーネルのソースディレクトリ内にある include/asm-generic/ioctls.h などを参照ください。 > socket なども /usr/include/bits/socket.h などにある値・ビットでしょ > うか。 ソケットについては同 include/linux/sockios.h などを参照ください。