This is an unofficial unauthorized fan page of a security enhanced Linux TOMOYO Linux developed by NTT DATA CORPORATION.
See TOMOYO Linux project for papers/materials.
I borrowed code names from dramatis personae of "Card Captor Sakura" created by CLAMP without permission of CLAMP.
When I released TOMOYO Linux in November 2005, its naming drew a mixed reaction. Therefore, I made this page to explain the origin of code names in my own.
The content of this page is what I kept only in my brain and other project members didn't know. Thus, there will be difference in awareness between project members.
TOMOYO Linux consists of the following 5 components.
Code Name | Denomination Date |
SAKURA Linux | 2003/07/07 |
TOMOYO Linux | 2003/12/01 |
CERBERUS | 2004/09/14 |
SYAORAN | 2004/10/30 |
YUE | 2004/12/24 |
This is named as initial letters of "Security Advancement Know-how Upon Read-only Approach for Linux".
Use of policy based mandatory access control (MAC) is an effective way to improve a system's security, but management of policy for MAC is a daunting task for system administrators and had been a barrier for introducing policy based MAC. Therefore, we set the security goal as "Tamper-proof" to relieve the system administrators of the tedious policy management task. We tried and succeeded to store almost all part of a system in a read-only medium so that a cracker cannot tamper with web contents or install backdoors, and I gave the code name "SAKURA Linux" to this project.
Originally, this code name meant know-how (e.g. installation manuals) that are essential for dividing a system into read-only components and read-write components. But now, it has some MAC functionality against operations that affect system wide (i.e. namespace manipulations).
Sakura, the cardcaptor, loves penguins very much. And speaking of penguins, it is Linux. Thus, this project was named as "SAKURA Linux".
This name is superimposed subtle pun of the Sakura's setting "Nobody can twist Sakura's essence" and the SAKURA's functionality "Nobody can tamper with files included in SAKURA".
SAKURA will feel lonely if she is alone, but she will get by all troubles if she is with her friends.
Original phrase was: "Daijoubu, Nantokanaruyo. Zettai, daijyoubudayo." ("It's all right. I can somehow get by. Yes, absolutely all right.")
This is named as initial letters of "Task Oriented Management Obviates Your Onus on Linux".
You can protect system files from tampering if you use "SAKURA Linux", but you cannot protect the system from leaking information as long as you don't introduce and manage policy based access control.
Therefore, we set the security goal as "Minimize the burden of policy management" while accepting policy based access control. We tried and succeeded to generate policy in our own style by tracking the history of program execution and recording access to system's resources.
Then, we attempted to convert from policy in our own style to policy in SELinux's style, but we failed to convert due to fundamental and structural difference.
But we thought that "We will be able to perform access control based on policy in our own style because we are able to generate policy in our own style by monitoring access to system's resources", and
we switched over to continue going our approach rather than following SELinux's approach, and we actually implemented access control functionalities.
We implemented "learning mode" that automatically generates policy, and this feature made it possible to dramatically reduce the burden of administrator's policy management, because what an administrator has to do is nothing but operate what an administrator wants to allow.
Since the "learning mode" that automatically records actual behaviors and saves the entire behaviors as policy resembles Tomoyo, the Sakura's friend who always associate with Sakura and records Sakura's behaviors on video tapes, this project was named as "TOMOYO Linux".
This name is superimposed subtle pun of the Tomoyo's setting "Tomoyo records Sakura's behaviors and generates battle costumes for Sakura that always perfectly fits" and the TOMOYO's functionality "TOMOYO records the system's behavior and generates policy that always perfectly fits".
TOMOYO will record the entire pattern of SAKURA's activity, and will protect SAKURA strongly when SAKURA is to be deceived.
You can get better security by using "SAKURA" and "TOMOYO" together.
Original phrase was: "Watashino shiawasewa Sakura changa shiawasede itekudasaru kotodesukara." ("It is my happiness that Sakura is being happy.")
This is named as initial letters of "Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security".
This is not a specific software implementation, but a concept for preventing attackers from spoofing by multiplexing login authentications using MAC.
It is necessity that "TOMOYO" and "CERBERUS" are good friends because "CERBERUS" utilizes TOMOYO Linux's policy structure.
The nickname is "Kero-chan check", isn't it? SAKURA Linux has a weakness because SAKURA Linux stores system files including password files in a read-only medium to avoid tampering, which means SAKURA Linux cannot change passwords. TOMOYO Linux recovers SAKURA Linux's weakness by forcibly restricting execution of programs and open of files.
"CERBERUS" is not the PAM (Pluggable Authentication Modules). You can use whatever methods (e.g. non password based authentication method) you want to use for authentication. You can enforce various authentications as many times as you want. Thus, you don't need to worry password brute-force attacks nor vulnerability in authentication modules. CERBERUS is beyond the bounds of common sense "You can perform login authentication only for once", and is the gatekeeper of the system.
Original phrase was: "Jinsei iroiroya! Ussyaar!" ("There are various events in a life. It's all right!")
This is named as initial letters of "Simple Yet All-important Object Realizing Abiding Nexus"
This is a filesystem for guaranteeing the correctness of files in /dev directory, where it is impossible to store in a read-only medium. This filesystem avoids tampering with files in /dev directory.
When I developed SAKURA Linux, I was using devfs for /dev directory (one of directories where it is not possible to mount for read-only mode). But mounting /dev directory for read-write mode means that there is a threat that an attacker with root privileges can tamper with files in /dev directory because he/she can delete device files in /dev directory. This threat has been recognized since October 2003, but it was impossible to develop original filesystem because I was a newbie and had little skill about kernel programming.
As I continued developing and improving TOMOYO Linux, I'm getting to understand the structure of the kernel and how the kernel works, and I succeeded to restrict device file's name and its attributes using policy, and I named this filesystem SYAORAN.
This name is superimposed subtle pun of the Syaoran's setting "Man of Destiny for Sakura" and the SYAORAN's functionality "breath of SAKURA's nostrils".
SYAORAN helps both SAKURA, who is antiskeptic, and TOMOYO, who acts based on the correctness of files.
This is named as initial letters of "Your User-role Enforcer".
This is not a specific software implementation, but a concept for providing RBAC (Role Based Access Control) like functionality by utilizing TOMOYO Linux's policy structure.
By dividing the administrative tasks into multiple roles and assigning different order of program execution for each role, you can give minimum necessary permissions for each role. You can do all administrative tasks (e.g. administrating web service, administrating mail service, administrating access logs) using only "root" account. Also, you can use with "CERBERUS", to assign different passwords for different roles.
Original phrase was: "Naniga shimpansyada. Kekkyoku saisyokara tugino Clow-card no motinushiwa kimattetanjyanaika." ("Hey, am I the 'adjudicator'? After all, the next owner of Clow cards is destined from the beginning.")
I didn't assign code names randomly, but I assigned code names based on the division of roles as shown below.
Firstly, categorize a system into "System Resources" and "System Users".
"SAKURA" and "SYAORAN" protects "System Resources" by avoiding tampering with files.
But you cannot avoid information leakages by only avoiding tampering with files.
To avoid information leakages, you need to restrict behavior of "System Users".
Here comes "TOMOYO". "TOMOYO" monitors user's actions against "SAKURA" and "SYAORAN", and forbids unauthorized actions.
You can obtain ordinary protections with "SAKURA" "TOMOYO" and "SYAORAN". But there are missing parts.
They are "countermeasures for impersonated logins" and "division of the administrative tasks".
There are possibilities of impersonated logins if login passwords are stolen or brute-forced by attackers.
Here comes "CERBERUS". "CERBERUS" performs extra login authentications that the only normal user knows how to pass, to beat back attackers who logged in using stolen or brute-forced passwords.
Also, since "TOMOYO" doesn't have a concept of users, it is impossible to split administrative tasks into parts by default.
Here comes "YUE". "YUE" directs administrators to different rooms where minimal permissions needed for each administrative task are given, to prevent other administrator from doing your administrative jobs.
"CERBERUS" and "YUE" have different denomination date, but these ideas were already fixed as of January 2004 and implemented at the same time.
Is it chance or necessity that the order of denomination date and the order of friends Sakura meets for the first time matched? ;-)
I tried to be faithful to the original as much as possible in my brain, but I couldn't reconstruct perfectly. Main differences are shown below.
In the original piece, Cerberus and Syaoran are at strife. But in TOMOYO Linux, they are not at strife.
In the original piece, Syaoran gets confused when he meets Yukito (Yue's temporal form). But in TOMOYO Linux, he doesn't. Since SYAORAN is a kernel component, it is not acceptable if he gets panic. ;-)
I wanted SAKURA to emerge at center stage, but since the aspect of TOMOYO became larger and larger from importance and technical point of view, this project was finally named as "TOMOYO Linux".
I can never reconstruct this. Security enhanced Linux is developed because there are malicious people in real world. Security enhanced Linux is not needed in the CCS's world because there are no malicious people in CCS's world.
TOMOYO Linux brings battles in the CCS's world to battles in real world, although the meaning and enemies are different. "SAKURA" "TOMOYO" "CERBERUS" "SYAORAN" "YUE" are characters involved in battles in the CCS's world. I saw blog entries that expects me to introduce other characters, but I don't have a plan to add other characters who are not involved in battles in the CCS's world.
I have the other reason for assigning these code names, but I don't write it in this page.