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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
