[tomoyo-users-en 418] Various news regarding TOMOYO Linux

Back to archive index
Tetsuo Handa from-****@I-lov*****
Fri Nov 11 21:49:39 JST 2011


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.




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