Hello. Today (the day with 6 repetitions of 1) is the 6th anniversary for TOMOYO 1 series since TOMOYO 1.0 was released as an open source software. ;-) However, no anniversary release today because I couldn't manage development schedule. Instead, various news is listed below. Firstly, I uploaded ccs-patch-1.8.3-20111111.tar.gz as TOMOYO 1.8.3p2. In order to make it easier to embed TOMOYO into devices with limited capacity for the kernel partition, I changed the way TOMOYO parses policy files and rearranged functions/variables. As a result, the object size was reduced by about 6% (on an x86_32 environment) while preserving functionality. Also, I introduced kernel config options for selectively excluding functionality unneeded for target environments. All syntaxes were recognized until TOMOYO 1.8.3p1 but syntaxes excluded by the kernel config options are no longer recognized in TOMOYO 1.8.3p2. This change applies to AKARI as well. Regarding TOMOYO 1.x's binary packages repository, I changed to use jaist.dl.sourceforge.jp rather than osdn.dl.sourceforge.jp as the download server. By this change, all rpm/deb downloads (other than these for Debian Lenny and Ubuntu 8.04 where apt does not accept HTTP redirection) should become faster. Jamie Nguyen has set up TOMOYO 1.8's binary packages repository for RHEL6 and Fedora 16 for both i686 and x86_64 architectures. While CentOS 6.1 is getting closer to release, http://qaweb.dev.centos.org/qa/node/116 I proposed TOMOYO 2.2 to CentOS+ kernel packages. http://bugs.centos.org/view.php?id=5219 Unless problems happen, TOMOYO 2.2 will become available in CentOS 6.1's CentOS+ kernels. By installing AKARI after installing CentOS+ kernel packages, users can observe/restrict directory entry manipulation operations using absolute pathnames. I think installation of x86_64 kernel packages is getting to be required for using as cloud computing's host environments. You will be able to install from CentOS+ repository if you want to use mainlined version of TOMOYO, will be able to install from Jamie's repository if you want to use fully functional version of TOMOYO, will be able to use AKARI if you want to use partially functional version without replacing kernel packages. tomoyo-tools-2.4 package for openSUSE 12.1 became ready. You can start using TOMOYO 2.4 on openSUSE 12.1. http://www.youtube.com/watch?v=MkBXGUb6RPo Linux 3.2-rc1 which includes TOMOYO 2.5 has been released. TOMOYO 2.5 supports restriction of network socket's destination addresses and environment variables. http://tomoyo.sourceforge.jp/2.5/chapter-3.html Also, you can divide permissions on per an Apache's virtual host basis using mod_tomoyo module. http://tomoyo.sourceforge.jp/2.5/chapter-13.html Ubuntu 12.04 LTS will include TOMOYO 2.5 because it will use Linux 3.2. https://lists.ubuntu.com/archives/kernel-team/2011-November/017719.html Finally, about development of TOMOYO 1.9. In TOMOYO 1.9, I'm planning to allow writing policy from the point of view of objects (in addition to policy from the point of view of subjects). Regarding conventional syntax Domainname_1 use_profile 3 Operation Target Condition Operation Target Condition Operation Target Condition Domainname_2 use_profile 2 Operation Target Condition Operation Target Condition "subject" controls "accessible objects" and "enforcing mode or not". Regarding new syntax, inverting like allow Operation Target Condition mode enforcing by Domainname_1 Condition by Domainname_2 Condition "object" controls "accessible subjects" and "enforcing mode or not". The characteristic point of the new syntax is that it acts as a sort of blacklisting because domainnames are checked only when all of Operation, Target and Condition are met. By making it possible to write policy from the point of view of objects, TOMOYO will need to check permissions regardless of the profiles associated to subjects. This destroys "disabled mode" which omits preparation for permission checks (e.g. calculating pathname of the requested file). Therefore, in TOMOYO 1.9, I'm planning to remove distinction among "disabled mode", "learning mode", "permissive mode" and "enforcing mode" and instead use "enforcing or not", and add permissions to policy from audit logs. By transferring the role of appending to policy from kernel to userspace in TOMOYO 1.9, as with the role of file_pattern was transferred from kernel to userspace in TOMOYO 1.8, we will obtain more flexible processing (at the cost of running ccs-auditd daemon for pumping the audit logs out of the kernel). I'm feeling that domain transition in TOMOYO 1.8 has became too complicated to document because policy namespace (reset_domain/no_reset_domain) and domain transition preference was introduced during TOMOYO 1.8.x. http://tomoyo.sourceforge.jp/1.8/policy-specification/domain-transition-procedure.html Therefore, I'm planning to reconstruct the way of specifying domain transition in TOMOYO 1.9. In TOMOYO 1.9, I aim for the realization of simple and easy-to-use specification by solving inconvenience caused by patching to existing syntaxes. There are a few more topics but I omit for now because they are too long to enumerate here and are not final plans. Maybe we would call it TOMOYO 3.0 rather than TOMOYO 1.9.