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
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
