Hello. I uploaded TOMOYO 1.7.1p1 which fixed the memory leak. http://osdn.dl.sourceforge.jp/tomoyo/43375/ccs-patch-1.7.1-20091220.tar.gz MD5: 8888488e0e704c4302480a0af476426c I'm now building binary packages. Files which contain 1.7.1p1 in their filenames are kernel packages built using above tar ball. http://sourceforge.jp/projects/tomoyo/releases/?package_id=10270 "Ubuntu 9.10 + TOMOYO 1.7.1p1" LiveCD and "CentOS 5.4 + TOMOYO 1.7.1p1" LiveCD are available. These LiveCDs use kernel packages built using above tar ball and can be used with AppArmor / SELinux respectively. http://tomoyo.sourceforge.jp/wiki-e/?TomoyoLive Some demonstration movies are also available. But webpages which explain these movies are not yet available. http://www.youtube.com/results?search_query=tomoyo+linux The file ccs-patch-1.7.1-20091220.tar.gz includes patch for 2.6.33-rc1 . TOMOYO 1.x is implemented without using "struct security_operations * security_ops;" so that TOMOYO can be used with SELinux/Smack/AppArmor etc. Since almost all LSM hooks which TOMOYO needs for implementing pathname based access control became available in 2.6.33 , patch for 2.6.33-rc1 embeds TOMOYO's original hooks into LSM hooks where possible. Diffstat of TOMOYO's original hooks for 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(-) Diffstat of TOMOYO's original hooks for 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(-) Since hooks provided by LSM are more widely called than hooks provided by TOMOYO, by embedding hooks provided by TOMOYO into hooks provided by LSM, permissions may be checked at locations where they were not checked until now. It will become impossible to distribute ready-made application's policy if application's policy depends on hardwares and filesystems. For example, if you are using stackable filesystem like below, you will need not only permission for pathname which application requested but also permission for pathname of underlying filesystem. # 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 If TOMOYO uses TOMOYO's original hook ( ccs_open_permission() ), only allow_read /tmp/mnt/file is required. But if TOMOYO uses LSM hook ( security_dentry_open() ), both allow_read /tmp/mnt/file allow_read /tmp/ro/file are required. It is impossible to force application policy developers to care about how users' filesystems are mounted. Therefore, I think LSM should be able to distinguish requests from applications and requests from kernel. But unfortunately, most of LSM hooks do not receive a hint to distinguish. Thus, it is not always advisable to embed TOMOYO's original hooks into LSM hooks wherever possible. In fact, I don't embed ccs_open_permission() into security_dentry_open(). Nonetheless, since implementations which don't use existing LSM hooks where possible likely be turned away at the door, this time I embedded TOMOYO's original hooks into LSM hooks where possible. Please test patch for 2.6.33-rc1. Please notify me if you found a problem. Regards.
TOMOYO
Fork