[tomoyo-users-en 138] Re: About TOMOYO 1.7.2

Back to archive index
SD sd.do****@yahoo*****
Tue Mar 23 01:05:15 JST 2010


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
> 


      




More information about the tomoyo-users-en mailing list
Back to archive index