Re: [RFC] TOMOYO Linux

[Toshiharu Harada <haradats@nttdata.co.jp>]

Stephen,

Thank you for your interests and comment.
I'm beginning to feel that you might be misunderstanding
my message. Let me explain.

Stephen Smalley wrote:
> On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
>> A couple of years ago, we tried to build a tool to generate
>> SELinux policy (*1). To do that, we had to gather the access
>> requests information. So we researched a profiling method and
>> got to the idea of having a process to store its invocation
>> history information (or ancestors).
>>
>> Here are examples:
>> /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash
>> /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash
>> /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash

"The idea":
If we let process to inherit the name of its ancestors (usualy starts
from /sbin/init), then Linux kernel will be able to know ancestors
for each process.

"Above examples" are:
examples of how we can distinguish the same /bin/bash processes.

> Why can't you do this via SELinux domain transitions?  That lets you do

What do you mean by "this" here?
I was not talking about MAC nor policy definitions.

> it by equivalence class rather than per-binary, and let's you just
> encode the security-relevant parts of the "invocation history" aka call
> chain.  For example, the above could be expressed in SELinux policy
> already as:

I might have confused you and I am sorry for that.
The above three lines are not TOMOYO Linux plicy.

> 	domain_auto_trans(getty_t, shell_exec_t, local_shell_t)
> 	domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t)
> 	domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t)
> or whatever you like.  But you don't have to keep extending it
> indefinitely when you don't need to distinguish in policy, so you might
> choose to entirely omit the last one, and just have it stay in
> remote_shell_t.

In your SELinux policy examples, someone must write down them.
To do that someone must know what will happen beforehands.
But if you use TOMOYO Linux, you'll get domain transition
information easily. The example of the result can be found here:

http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=policy-sample
(choose whatever distribution and open the link for
"domain_policy.txt")

For example, from http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos4.4/domain_policy.txt?v=policy-sample#L4564
you will know:

/bin/cp which was invoked from
   /usr/bin/makewhatis which was invoked from
     /etc/cron.weekly/00-makewhatis.cron which was invoked from
       /usr/bin/run-parts which was invoked from
         /bin/bash which was invoked from
           /usr/sbin/crond

that /bin/cp process needs to

read /dev/null, /etc/selinux/config, /proc/filesystems, and
write /var/cache/man/whatis, and truncate /var/cache/man/whatis.

We implemnted the above mentioned idea and TOMOYO Linux is a
sample system which use distinguished process as a "domain".
In some sense it is a system analyzing tool.

Again, we intended to share the idea to people on the lkml.
MAC (TOMOYO Linux) is just a sample.
Any feedback will be appreciated.

>> It seemed to us that this clarification would be familiar to
>> users/administrators and could be used for various purposes.
>> We did implement this by making use of the Linux's traditional
>> fork & exec mechanisms, and built a pathname-based MAC using
>> this implementation. We named the result as "TOMOYO Linux"
>> and made it open source at SourceForge.jp (*2).
>>
>> TOMOYO Linux kernel keeps track of process invocation and
>> distinguishes every different process invocation history as a "domain".
>> TOMOYO Linux can accumulate the accesses requests for each domain.
>>
>> TOMOYO Linux has a utility called "ccstree". It prints the invocation
>> history for each process in addition to the output of "pstree" command:
>>
>> [root@tomoyo ~]# ccstree
>> init (1) <kernel> /sbin/init
>>    +- udevd (388) <kernel> /sbin/udevd
>>    ...
>>    +- automount (1970) <kernel> /etc/rc.d/init.d/autofs /usr/sbin/automount
>>    +- acpid (1993) <kernel> /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid
>>    +- cupsd (2008) <kernel> /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd
>>    +- sshd (2026) <kernel> /usr/sbin/sshd
>>    +- sshd (2269) <kernel> /usr/sbin/sshd
>>      +- bash (2271) <kernel> /usr/sbin/sshd /bin/bash
>>        +- ccstree (15125) <kernel> /usr/sbin/sshd /bin/bash /root/ccstools/ccstree
>>
>>    (symbol, "<kernel>" indicates a virtual base.)
>>
>> We had a presentation and a tutorial session of TOMOYO Linux
>> version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and
>> has a rich set of MAC functions for files, networking, and
>> capabilities and so on. For historical reasons, it is not using
>> LSM or auditd. We decided to share this idea with the Linux community
>> and totally rewrote the code. The result was TOMOYO Linux 2.0,
>> which is now using LSM and auditd. To make discussion smooth,
>> we cut off MAC functions other than for files.
>>
>> We are posting this message because we believe that this process
>> invocation history idea might be a useful addition to Linux.
>> Please take some time to see what this small piece of software can do
>> with your own eyes. Your feedback will be greatly appreciated.
>>
>> If some of you are interested in TOMOYO Linux as a method for
>> access control, please be advised to try full-featured version 1.4.1 (*4).
>> It is quite easy to install and maintain TOMOYO Linux, but it should
>> not be considered as a replacement of SELinux.
>>
>> All right, that's almost everything. Please visit the following
>> URL for the code and documents:
>>    http://tomoyo.sourceforge.jp/wiki-e/
>> If you want to see the code first, then:
>>    http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/?v=linux-2.6.21.3-tomoyo-2.0
>>
>> We will have a TOMOYO Linux BOF session at the OLS2007 (*5).
>> Please come along and let's talk.
>>
>> Thank you.
>>
>> Toshiharu Harada (project manager)
>> Tetsuo Handa (main architect, version 1 author)
>> Kentaro Takeda (version 2.0 author)
>> NTT DATA CORPORATION
>> http://www.nttdata.co.jp/en/index.html
>>
>> *1) http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf
>> *2) http://tomoyo.sourceforge.jp/
>> *3) http://www.celinux.org/elc2007/
>>      http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
>> *4) http://tomoyo.sourceforge.jp/en/1.4.1/
>> *5) http://www.linuxsymposium.org/2007/