"'TOMOYO Linux' is our work in the field of security enhanced Linux," Kentaro Takeda began, describing 15 patches posted to the Linux Kernel mailing list. He noted that in an earlier version of the patches posted just prior to the recent Kernel summit, TOMOYO Linux's Mandatory Access Control was limited to files. In the new patch, he explained, "now TOMOYO Linux has access control functionality not only for files but also for networking, signal transmission and namespace manipulation and we got the source code cleaned-up." Kentaro went to provide an overview:

"The fundamental concept of TOMOYO Linux is 'tracking process invocation history'.

"The 'struct task_struct'->security member holds a pointer to the 'process invocation history'. Thus, every process (the kernel, /sbin/init process and any children/descendant of /sbin/init) knows its 'process invocation history' (or ancestors). Since every process knows its ancestors, TOMOYO Linux can enforce access control over all processes."

"Smack is the Simplified Mandatory Access Control Kernel," Casey Schaufler said posting the third version of his patchest. He explained, "Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data." Casey continued:

"Smack is implemented as a clean LSM. It requires no external code changes and the patch modifies only the Kconfig and Makefile in the security directory. Smack uses extended attributes and provides a set of general mount options, borrowing technics used elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides a pseudo-filesystem smackfs that is used for manipulation of system Smack attributes."

Andrew Morton replied to Casy's lengthy description, "I don't know enough about security even to be dangerous. I went back and reviewed the August thread from your version 1 submission and the message I take away is that the code has been well-received and looks good when considered on its own merits, but selinux could probably be configured to do something sufficiently similar." He added, "so with the information which I presently have available to me, I'm thinking that this should go into 2.6.24."