Thanks for your program. I would like to ask a question. Why is it difficult to filter IP requests on kernel higher 2.6.30? I am quite happy that TOMOYO 1.6.8 can filter network requests. Why can't we do the same on kernel after 2.6.30? Thanks. --- On Mon, 3/22/10, Tetsuo Handa <from-****@I-lov*****> wrote: > From: Tetsuo Handa <from-****@I-lov*****> > Subject: [tomoyo-users-en 137] About TOMOYO 1.7.2 > To: tomoy****@lists***** > Date: Monday, March 22, 2010, 5:12 PM > Hello. > > I'm planning to release TOMOYO 1.7.2 on April 1st. > It contains three enhancements. > > (1) Allow domain transition without execve(). > > To be able to split permissions for Apache's > CGI programs which are > executed without execve(), I added special > domain transition which is > performed by atomically writing > '\0'-terminated binary string to > /proc/ccs/.transition interface. > > For example, a process which belongs to > "<kernel> /usr/sbin/httpd" domain > will transit to "<kernel> > /usr/sbin/httpd //app=cgi1\040id=10000" domain > by atomically writing "app=cgi1 id=10000" + > '\0' to /proc/ccs/.transition > using Apache's ap_hook_handler() > functionality. > > Note that '\0'-terminated binary string is > converted to TOMOYO's string > inside kernel and prefix "//" is > automatically added to the string so that > domainname does not conflict with domainnames > created by execve(). > Without this prefix, if "<kernel> > /usr/sbin/sshd /bin/bash" domain is > allowed to open /proc/ccs/.transition for > writing and > "<kernel> /usr/sbin/sshd /bin/bash > /usr/bin/passwd" domain is allowed to > access /etc/shadow , /bin/bash will be able > to access /etc/shadow by > atomically writing "/usr/bin/passwd" + '\0' > to /proc/ccs/.transition . > Allowing /bin/bash to access /etc/shadow is > not what people want. > > Permission for this operation is checked by > "allow_transit" keyword. > Unlike "allow_execute" keyword, the string > parameter for "allow_transit" > keyword does not refer a real file on > filesystem's namespace. Therefore, > you can store any combination of parameters > like LDAP's DN entry in the > string parameter for "allow_transit" > keyword. > > (2) Allow building TOMOYO as a loadable kernel module. > > On embedded systems, there is a partition > (e.g. /dev/mtdblock1) dedicated > for vmlinuz file. Users have to adjust their > kernel configs in order to fit > vmlinuz to the partition. I tried Silicon > Linux's CAT760 (SH4 architecture) > and found that the size of vmlinuz exceeds > the size of the partition by > applying TOMOYO's patch > (ccs-patch-1.7.1-20100214.tar.gz). > > Of course, it is possible to resize the > partition. But since CAT760's > kernel config supports loadable kernel > modules, I thought it is better to > build TOMOYO as a loadable kernel module if > it is possible to do so. > > TOMOYO can track TOMOYO's domain tree > information as long as TOMOYO is > activated when /sbin/init starts. Thus, > TOMOYO can work fine if TOMOYO's > kernel module is loaded by initramfs or by > /sbin/ccs-init . > > To split TOMOYO as a loadable kernel module, > I introduced an indirection > layer similar to LSM's "struct > security_operations". Also, I added kernel > command line parameter that allows disabling > TOMOYO 1.7.2 upon boot in case > of emergency. > > Modifications against vmlinuz are > > @ Hooks which TOMOYO 1.7.2 needs. > (ccs-patch-2.\*.diff) > @ Header files. (ccsecurity.h and > ccsecurity_vfs.h) > @ Policy loader launcher. > (load_policy.c) > @ A few EXPORT_SYMBOL_GPL() which > TOMOYO 1.7.2 needs. > > All other components are detached from > vmlinuz . > Regarding filesize increment of vmlinuz for > CAT760 was reduced by 44KB. > (Filesize of gzipped TOMOYO's kernel module > is about 57KB.) > > Although patching the kernel source and > recompiling the kernel are > inevitable, this change will make it easier > to enable TOMOYO Linux > when there is a filesize limitation on > vmlinuz. > > I'm planning to make it possible for TOMOYO > 2.x to compile as loadable > kernel module like TOMOYO 1.7.2 does. > Debian is considering enabling TOMOYO 2.2 for > Squeeze, but the filesize > increment of vmlinuz remains as the last > problem. > http://osdir.com/ml/debian-bugs-dist/2010-02/msg08758.html > The filesize increment problem will become > clearer when AppArmor is > merged into mainline. I don't want > distributors to worry about size of > vmlinuz by compiling > SELinux/Smack/TOMOYO/AppArmor into vmlinuz . > If TOMOYO 2.x becomes a loadable kernel > module, filesize increment by > TOMOYO will become negligible. > Of course, you can make TOMOYO 2.x as > built-in even if TOMOYO 2.x became a > loadable kernel module. But please let me > know if you don't want TOMOYO 2.x > to become a loadable kernel module. > > (3) Improve garbage collector. > > Until now, garbage collector did not start > garbage collection until > /proc/ccs/ users call close(). But since it > is not good behavior to leave > the kernel with SRCU read lock held, I > changed /proc/ccs/ users not to > leave the kernel with SRCU read lock held. As > a result, garbage collector > can start garbage collection before > /proc/ccs/ users call close(). > > _______________________________________________ > tomoyo-users-en mailing list > tomoy****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en >