Hello,
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
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/
On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
> Hello,
>
> 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
Why can't you do this via SELinux domain transitions? That lets you do
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:
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.
> 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-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Stephen Smalley
National Security Agency
2007/6/13, Stephen Smalley <[email protected]>:
> On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
> > 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
>
> Why can't you do this via SELinux domain transitions? That lets you do
> 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:
> 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.
The above SELinux policy looks similar to the one I wrote, but
that is not very true. Because in my example, path name corresponds to a file
while local_shell_t are bound to multiple.
I understand the advantages of label, but it needs to be
translated to human understandable form of path name.
So I think pathname based call chains are advantages for
at least auditing and profiling.
--
Toshiharu Harada
[email protected]
On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote:
> 2007/6/13, Stephen Smalley <[email protected]>:
> > On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
> > > 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
> >
> > Why can't you do this via SELinux domain transitions? That lets you do
> > 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:
> > 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.
>
> The above SELinux policy looks similar to the one I wrote, but
> that is not very true. Because in my example, path name corresponds to a file
> while local_shell_t are bound to multiple.
> I understand the advantages of label, but it needs to be
> translated to human understandable form of path name.
> So I think pathname based call chains are advantages for
> at least auditing and profiling.
Well, not to get into a debate, but think about whether
"/usr/sbin/sshd /bin/bash" and "/sbin/mingetty /bin/bash" is more
understandable to an administrator than "remote shell" vs. "local shell"
- the label-based approach lets you map the low-level detail of
individual programs/pathnames to abstract equivalence classes that are
more understandable, not less. Further, think about the advantages of
being able to encode only the security-relevant invocations, not all of
them.
On a different note, from a quick look, it looks like TOMOYO is AppArmor
+ invocation history from a user perspective. Plus a wider range of
controls in your original implementation, but your LSM implementation
seems to be just getting started and only deals with files. So what's
the case for having a whole separate security module vs. a small
extension to AppArmor?
--
Stephen Smalley
National Security Agency
Toshiharu Harada wrote:
> So I think pathname based call chains are advantages for
> at least auditing and profiling.
SELinux audit logs (well, whatever is in /var/log/audit on
my system) does show the path names of objects that fail to
be accessed as well as the name and context of the processes
trying to access them.
This is with standard Fedora and RHEL installations.
--
All Rights Reversed
2007/6/14, Rik van Riel <[email protected]>:
> > So I think pathname based call chains are advantages for
> > at least auditing and profiling.
>
> SELinux audit logs (well, whatever is in /var/log/audit on
> my system) does show the path names of objects that fail to
> be accessed as well as the name and context of the processes
> trying to access them.
>
> This is with standard Fedora and RHEL installations.
Thank you for your comment.
SELinux has a well designed robust and flexible functions.
So it should be used for everywhere. I understand it.
As you mentioned one can analyze the system (process)
behaviors from AVC logs. But the maintenance cost is not trivial.
If logging with process context is the only purpose,
current TOMOYO Linux can do it with no hustle at all.
Installation takes just 15 minutes. Please think it as something like
TOYOTA Prius. It's a compact and economical car.
Volvo is known by its security, but we don't have to use only Volvo.
TOMOYO Linux and its underlying idea are free and
you don't have to find a garage. :-)
Cheers,
Toshiharu Harada
Toshiharu Harada wrote:
> 2007/6/14, Rik van Riel <[email protected]>:
>> > So I think pathname based call chains are advantages for
>> > at least auditing and profiling.
>>
>> SELinux audit logs (well, whatever is in /var/log/audit on
>> my system) does show the path names of objects that fail to
>> be accessed as well as the name and context of the processes
>> trying to access them.
>>
>> This is with standard Fedora and RHEL installations.
>
> Thank you for your comment.
>
> SELinux has a well designed robust and flexible functions.
> So it should be used for everywhere. I understand it.
> As you mentioned one can analyze the system (process)
> behaviors from AVC logs. But the maintenance cost is not trivial.
>
> If logging with process context is the only purpose,
> current TOMOYO Linux can do it with no hustle at all.
Yes, but so does standard SELinux.
You are making me curious: what does TOMOYO do that is
not done by regular SELinux?
Logging with process name, path name and contexts is
already done. I must have missed some other TOMOYO
feature in your initial email...
--
All Rights Reversed
2007/6/14, Rik van Riel <[email protected]>:
> Toshiharu Harada wrote:
> > 2007/6/14, Rik van Riel <[email protected]>:
> > SELinux has a well designed robust and flexible functions.
> > So it should be used for everywhere. I understand it.
> > As you mentioned one can analyze the system (process)
> > behaviors from AVC logs. But the maintenance cost is not trivial.
> >
> > If logging with process context is the only purpose,
> > current TOMOYO Linux can do it with no hustle at all.
>
> Yes, but so does standard SELinux.
>
> You are making me curious: what does TOMOYO do that is
> not done by regular SELinux?
>
> Logging with process name, path name and contexts is
> already done. I must have missed some other TOMOYO
> feature in your initial email...
I see SELinux can log with process name, path name and
contexts, but "contexts" must be defined beforehand.
TOMOYO Linux kernel does that with pathname, so no
label definitions needed.
You can confirm the process (domain) transitions any time
and access occurred are clarified per domain basis automatically.
Security context in TOMOYO Linux is represented and stored
as a call chain and very intuitive.
TOMOYO Linux has a mode called "learning"
in addition to "permissive" and "enforce". You can easily
get the TOMOYO Linux policy with learning mode that
SELinux does not have. In addition, access control mode of
TOMOYO Linux can be managed for every difference domain.
--
Toshiharu Harada
[email protected]
On Thu, 14 Jun 2007, Toshiharu Harada wrote:
> TOMOYO Linux has a mode called "learning"
> in addition to "permissive" and "enforce". You can easily
> get the TOMOYO Linux policy with learning mode that
> SELinux does not have.
Blindly generating security policy through observation of the system is
potentially dangerous for many reasons.
See
<http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/>
Note that while SELinux does also have a similar capability with the
audit2allow tool, it should be considered an expert tool, the output of
which needs to be understood before use (as noted in its man page).
> In addition, access control mode of
> TOMOYO Linux can be managed for every difference domain.
We have considered per-domain enforcing mode a couple of times in the
past, but figured that it could be implemented via policy alone (e.g. run
the task in a domain where all accesses are allowed and logged); and it
would also be of limited usefulness because of the aforementioned problems
with learning mode security policy.
- James
--
James Morris
<[email protected]>
On Thu, 14 Jun 2007, Toshiharu Harada wrote:
> 2007/6/14, Rik van Riel <[email protected]>:
>> Toshiharu Harada wrote:
>> > 2007/6/14, Rik van Riel <[email protected]>:
>> > SELinux has a well designed robust and flexible functions.
>> > So it should be used for everywhere. I understand it.
>> > As you mentioned one can analyze the system (process)
>> > behaviors from AVC logs. But the maintenance cost is not trivial.
>> >
>> > If logging with process context is the only purpose,
>> > current TOMOYO Linux can do it with no hustle at all.
>>
>> Yes, but so does standard SELinux.
>>
>> You are making me curious: what does TOMOYO do that is
>> not done by regular SELinux?
>>
>> Logging with process name, path name and contexts is
>> already done. I must have missed some other TOMOYO
>> feature in your initial email...
>
> I see SELinux can log with process name, path name and
> contexts, but "contexts" must be defined beforehand.
> TOMOYO Linux kernel does that with pathname, so no
> label definitions needed.
> You can confirm the process (domain) transitions any time
> and access occurred are clarified per domain basis automatically.
> Security context in TOMOYO Linux is represented and stored
> as a call chain and very intuitive.
>
> TOMOYO Linux has a mode called "learning"
> in addition to "permissive" and "enforce". You can easily
> get the TOMOYO Linux policy with learning mode that
> SELinux does not have. In addition, access control mode of
> TOMOYO Linux can be managed for every difference domain.
This sounds a like like feature differences "compared" at:
http://www.novell.com/linux/security/apparmor/selinux_comparison.html
--
William Leibzon
Elan Networks
[email protected]
Morris, thank you for your comment.
2007/6/14, James Morris <[email protected]>:
> On Thu, 14 Jun 2007, Toshiharu Harada wrote:
>
> > TOMOYO Linux has a mode called "learning"
> > in addition to "permissive" and "enforce". You can easily
> > get the TOMOYO Linux policy with learning mode that
> > SELinux does not have.
>
> Blindly generating security policy through observation of the system is
> potentially dangerous for many reasons.
> See
> <http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/>
>
When I saw Russell Coker and showed him a demonstration of
TOMOYO Linux, he told the same comment.
Also after tracing an AppAmor's long thread, I'm convinced of the
meaning of label base. That's why I don't think TOMOYO Linux as a
replace of SELinux. "Professional policy (or reference policy)"
makes sense to me.
However it may be safe for audition and profiling purpose.
Policy learning feature of TOMOYO Linux will help
understanding the behavior of Linux boxes.
That is my point.
I will double check the link you showed me. Thank you.
(It's wonderful to receive comments from you and Stephen!)
> Note that while SELinux does also have a similar capability with the
> audit2allow tool, it should be considered an expert tool, the output of
> which needs to be understood before use (as noted in its man page).
Yes. But I remember Frank said "don't use it :-)" when he gave a
presentation in Japan.
> > In addition, access control mode of
> > TOMOYO Linux can be managed for every difference domain.
>
> We have considered per-domain enforcing mode a couple of times in the
> past, but figured that it could be implemented via policy alone (e.g. run
> the task in a domain where all accesses are allowed and logged); and it
> would also be of limited usefulness because of the aforementioned problems
> with learning mode security policy.
I'll reply this part in later.
Thanks!
Toshiharu Harada
On Wed, 2007-06-13 at 16:32 -0700, william(at)elan.net wrote:
> On Thu, 14 Jun 2007, Toshiharu Harada wrote:
>
> > 2007/6/14, Rik van Riel <[email protected]>:
> >> Toshiharu Harada wrote:
> >> > 2007/6/14, Rik van Riel <[email protected]>:
> >> > SELinux has a well designed robust and flexible functions.
> >> > So it should be used for everywhere. I understand it.
> >> > As you mentioned one can analyze the system (process)
> >> > behaviors from AVC logs. But the maintenance cost is not trivial.
> >> >
> >> > If logging with process context is the only purpose,
> >> > current TOMOYO Linux can do it with no hustle at all.
> >>
> >> Yes, but so does standard SELinux.
> >>
> >> You are making me curious: what does TOMOYO do that is
> >> not done by regular SELinux?
> >>
> >> Logging with process name, path name and contexts is
> >> already done. I must have missed some other TOMOYO
> >> feature in your initial email...
> >
> > I see SELinux can log with process name, path name and
> > contexts, but "contexts" must be defined beforehand.
> > TOMOYO Linux kernel does that with pathname, so no
> > label definitions needed.
> > You can confirm the process (domain) transitions any time
> > and access occurred are clarified per domain basis automatically.
> > Security context in TOMOYO Linux is represented and stored
> > as a call chain and very intuitive.
> >
> > TOMOYO Linux has a mode called "learning"
> > in addition to "permissive" and "enforce". You can easily
> > get the TOMOYO Linux policy with learning mode that
> > SELinux does not have. In addition, access control mode of
> > TOMOYO Linux can be managed for every difference domain.
>
> This sounds a like like feature differences "compared" at:
> http://www.novell.com/linux/security/apparmor/selinux_comparison.html
Amazing, per that table, AppArmor is better in every way than SELinux.
Nothing like an unbiased and fair-minded comparison.
--
Stephen Smalley
National Security Agency
Hello.
James Morris wrote:
> Note that while SELinux does also have a similar capability with the
> audit2allow tool, it should be considered an expert tool, the output of
> which needs to be understood before use (as noted in its man page).
Yes, adding "allow" statement without understanding what the statement means
is dangerous.
But regarding TOMOYO Linux, "allow" statement that needs to be added
to grant requested access is quite easy for human to understand.
This helps administrator understand what will be allowed before allowing it.
For example, if "allow foo_t bin_t:execute" (sorry, I don't know proper
SELinux's policy syntax) statement is shown to an administrator,
he/she has to understand what programs belongs to bin_t before
adding this statement, for some files may be exposed (if /bin/cat is bin_t)
or some files may be deleted (if /bin/rm is bin_t).
But if "allow execute /bin/cat" statement is shown to an administrator,
he/she can easily understand what will happen because
only programs that are accessible via the pathname /bin/cat can be executed.
People assumes and expects that /bin/cat is a program that prints
the content of files, /usr/share/doc is a directory for shared documents,
/tmp is a directory for temporaly files and so on.
I know you worry about symlinks, chroots, bind mounts and private namespaces.
TOMOYO Linux solves all symlinks and traverses up to namespace's root
so that /bin/cat is exactly /bin/cat and nothing else
(e.g. /tmp/cat or /var/chroot/bin/cat, where /tmp/cat is a malicious program).
TOMOYO Linux restricts mount related operations to make sure
/bin is not a bind mount of /tmp and /bin/cat is not an alias of /tmp/cat .
TOMOYO Linux restricts modification of /bin/cat by not giving processes
write permission to /bin/cat unless needed.
TOMOYO Linux's way is respect pathnames and try to keep meaning of pathnames
unchanged as hard as possible so that the system can provide files
which poeple assumes and expects.
I know respecting pathnames will crash if the systems need complicated
namespace manipuration like shared subtree or overlay mounts.
For such systems, the only choice is label based access control.
But I think many systems don't need complicated namespace manipuration.
For such systems, both label based and pathname based access control
are possible choice.
> We have considered per-domain enforcing mode a couple of times in the
> past, but figured that it could be implemented via policy alone (e.g. run
> the task in a domain where all accesses are allowed and logged); and it
> would also be of limited usefulness because of the aforementioned problems
> with learning mode security policy.
If there were only "disabled" and "enforcing" modes,
per-domain enforcing mode would not be useful.
The development of TOMOYO Linux's policy starts from scratch
and builds up step by step for all domains.
If I use "enforcing mode but allows everything" approach,
it becomes impossible to develop policy using "learning" and "permissive" modes
where some of domains are already in enforcing mode but the rests are not yet.
At least, per-domain enforcing mode is useful for TOMOYO Linux.
Thanks.
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/
Stephen Smalley wrote:
> On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote:
>> 2007/6/13, Stephen Smalley <[email protected]>:
>>> On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
>>>> 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
>>> Why can't you do this via SELinux domain transitions? That lets you do
>>> 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:
>>> 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.
>> The above SELinux policy looks similar to the one I wrote, but
>> that is not very true. Because in my example, path name corresponds to a file
>> while local_shell_t are bound to multiple.
>> I understand the advantages of label, but it needs to be
>> translated to human understandable form of path name.
>> So I think pathname based call chains are advantages for
>> at least auditing and profiling.
>
> Well, not to get into a debate, but think about whether
> "/usr/sbin/sshd /bin/bash" and "/sbin/mingetty /bin/bash" is more
> understandable to an administrator than "remote shell" vs. "local shell"
> - the label-based approach lets you map the low-level detail of
> individual programs/pathnames to abstract equivalence classes that are
> more understandable, not less. Further, think about the advantages of
> being able to encode only the security-relevant invocations, not all of
> them.
With our sample implmentation of "automated process invocation
history tracking system" (or TOMOYO Linux, in short :)),
no domain transition design and definition is needed.
All you have to do is just run the kernel.
So limiting to encode does not matter much.
> On a different note, from a quick look, it looks like TOMOYO is AppArmor
> + invocation history from a user perspective. Plus a wider range of
> controls in your original implementation, but your LSM implementation
> seems to be just getting started and only deals with files. So what's
> the case for having a whole separate security module vs. a small
> extension to AppArmor?
The reason we cut off various MAC controls was to make
the code as small as possible (we knew lkml readers are busy).
If AA would merge the TOMOYO Linux's "automated proccess
invocation history tracking system" and "real-time policy
learning system", I would be fine.
Cheers,
Toshiharu Harada
Hello.
I just now made demo movies how TOMOYO Linux looks like.
http://tomoyo.sourceforge.jp/data/CentOS5-install.avi is
a movie that demonstrates how to install TOMOYO Linux 1.4.1 on CentOS 5.
http://tomoyo.sourceforge.jp/data/CentOS5-learning.avi is
a movie that demonstrates how the TOMOYO Linux kernel creates domains
and accumulates access requests from scratch using "learning" mode.
Please see CentOS5-install.avi once before seeing CentOS5-learning.avi
to help your understanding.
Although there is no explanation text in the movies for now,
I'm sure you can feel how TOMOYO Linux works.
Thanks.