This is a summary of correspondence between me and Tetsuo Handa, which I inadvertantly did not post onto the mailing list. Following this discussion, Tetsuo very kindly created a comprehensive comparison table between AKARI, TOMOYO Linux 1.x and 2.x http://akari.sourceforge.jp/comparison.html Unquoted text is Tetsuo's response to my relentless questions. Jamie Nguyen wrote: >It seems I somehow overlooked AKARI. It is clear that the primary >advantage of AKARI is that the kernel does not need to be recompiled, >which is great! Are there any disadvantages or other differences from >using AKARI instead of patching the kernel with ccs-patch-1.x? AKARI is based on ccs-patch 1.8. There are two disadvantages. One is that LSM hooks provided by a kernel depends on kernel version and kernel configuration (whereas ccs-patch-\*.diff is version/configuration independent). You can use AKARI on (e.g.) Fedora 14 and RHEL6 but you can't use absolute pathnames for directory modification operations (e.g. mkdir()) because they don't have CONFIG_SECURITY_PATH enabled. Also, a few LSM hooks which TOMOYO wants (e.g. hooks for recvmsg()/capabilities/signals) are not provided. The other is that looking up per-task variables used by AKARI is slower than TOMOYO because these variables are managed outside "struct task_struct" in order to keep KABI unchanged. (Well, TOMOYO 1.8 got a option to manage these variables outside "struct task_struct" in a way AKARI does in order to keep KABI unchanged.) > I gather in an earlier posting of yours on the ML that AKARI only has > support for x86_32, whereas ccs-patch supports multiple architectures. > Is this still true? AKARI now supports x86_64. But I haven't tested other architectures because I don't have access to other architectures. I'm planning to test using QEMU but I have no time for now. > Is there an interface in AKARI to alter kernel > options such as the maximal count for learning mode/grant log/reject > log that are available to change when compiling ccs-patch into the > kernel? Currently the content of Kconfig is hard coded because I don't know how to use Kconfig for extra modules without modifying existing Kconfig files. But you can override kernel options using /etc/ccs/profile.conf . > And is recvmsg() the only function unavailable in AKARI compared to > TOMOYO Linux 1.x No. (1) Restricting recvmsg() operation is impossible for AKARI because LSM hook for doing permission checks based on sender's address information is missing. TOMOYO 1.x inserts a hook for doing it. TOMOYO 1.x discards the datagram and returns EAGAIN error to the caller if permission denied. (2) The timing of checking permission for accept() operation based on sender's address information differs for TOMOYO 1.x and AKARI. The former checks it before returning to the caller. The former discards the accept()ed socket and returns EAGAIN error to the caller if permission denied. The latter checks it upon first use of the accept()ed socket. The latter returns -EPERM error to the caller if permission denied. (3) Restricting use of capability is impossible for AKARI because LSM hooks for doing it are missing (or exist but are located where it is not permitted to do operations that may sleep). (4) Restricting sending signals is impossible for AKARI because LSM hook for doing it exists but that hook is located where it is not permitted to do operations that may sleep. (5) Restricting file operations heavily depends on kernel version and kernel config. If kernel version >= 2.6.33 and CONFIG_SECURITY_PATH=y, AKARI can do same restrictions which TOMOYO can do. If kernel version >= 2.6.29 and CONFIG_SECURITY_PATH=y, AKARI can do same restrictions which TOMOYO can do except chmod()/chown()/chroot(). If kernel version >= 2.6.24, AKARI can do same permission check for open() operation which TOMOYO can do. For kernel version < 2.6.24, AKARI checks more read/write permissions than TOMOYO checks because AKARI has to use security_inode_permission() hook which is called by not only open() operation but also other operations (e.g. creat()). If kernel version >= 2.6.33 and CONFIG_SECURITY_PATH=y, you can use absolute pathnames for directory modification operations. Otherwise, you can't use absolute pathnames for directory modification operations. There could be more difference. (6) Restricting implicit local port assignment is impossible for AKARI because LSM hook for doing it is missing. >I think this marks the end of my string of questions. I will post a >summary of our correspondence to the mailing list. Thank you so much >for your time and thorough responses. Good luck! :-) > >Kind regards
TOMOYO
Fork