This document is intended to specify the security goal that TOMOYO Linux is
trying to achieve, so that users can evaluate whether TOMOYO Linux will meet
their needs, and kernel developers can evaluate whether TOMOYO Linux deserved
to be in-tree.
1. About TOMOYO Linux
Project Homepage: http://tomoyo.sourceforge.jp/index.html.en
Project Wiki: http://elinux.org/TomoyoLinux
TOMOYO Linux is a DIY tool for understanding and protecting your system.
TOMOYO Linux policy definitions are absolutely readable to Linux users, and
TOMOYO Linux supports unique policy learning mechanism which automatically
gathers information and arranges the results as policy definitions.
These things made it possible for users to write policy from scratch.
Troubleshooting can be done by users.
We put some TOMOYO Linux policy examples on our web site.
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample
2. TOMOYO Linux Security Goal
The TOMOYO Linux's security goal is to provide "MAC that covers practical
requirements for most users and keeps usable for most administrators".
TOMOYO Linux is not a tool for security professional but for average users
and administrators.
3. Our Approach
To meet the above goal, TOMOYO Linux attempts to make the system where
everything is prearranged in an easy-to-understand way.
* Make the all subject's all access requests that will occur at least once
during the lifetime of the kernel known in advance.
* Let the administrator understand what access requests will each subject
raise in his/her system and write policy which only allows expected and
desirable access requests for his/her needs.
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from
attackers exploiting vulnerabilities in applications that the system hosts.
The threat is that an attacker can cause a vulnerable application to do
something unexpected and undesirable. TOMOYO Linux addresses this threat by
recording all applications' behaviors in the test environment and forcing
all applications behave within recorded behaviors in the production environment.
TOMOYO Linux has a unique concept of "process invocation history"
(in short, PIH). The PIH is a developmental lineage of a process.
When a process executes a program, the process creates a copy with fork() and
replace the copy with execve().
TOMOYO Linux appends the pathname of the executed program to the PIH of
the replaced process, and associates process's PIH (stored in task_struct)
with a domain.
As a result, the context switching (a.k.a. domain transition) is unidirectional.
This rule allows administrator distinguish and manage fine-grained context.
Domain transition forms tree structure like a directory tree of filesystems.
Each domain has different set of permissions that are essential for that domain.
4. Things you can do with TOMOYO Linux.
Create policy from scratch.
You want to use ready-made policy files supplied by somebody else
because testing all paths needed for your usage sounds boring?
OK, then you can choose other implementations that provide
ready-made policy files, but you should check whether these files
contain enough permissions for your usage or not. It is inevitable thing
to test all paths needed for your usage if you want to use white listing
access control.
Also, ready-made policy files tend to contain redundant permissions
for your usage which often leads to serious problem.
TOMOYO Linux is a DIY tool for understanding and protecting your Linux box.
TOMOYO Linux's "learning mode" will automatically generate
policy files with necessary and sufficient permissions for you.
Understand all possible requests.
TOMOYO Linux reports what is happening within your Linux box.
You can have the security of knowing that no unexpected requests arise,
if you have tested all paths needed for your usage.
Please remember, we are not saying that
"You can have the security of knowing that no unexpected results happen".
Although TOMOYO Linux attempts to filter the request as hard as possible,
TOMOYO Linux can't guarantee the result.
Analyze system's behavior.
TOMOYO Linux resembles to /usr/bin/strace .
TOMOYO Linux reports what programs are executed from each program and
what files/networks are accessed by each program.
You can use TOMOYO Linux for analyzing application's behavior
if you want to know "which configuration file does this daemon read?",
"what port numbers does this daemon require?" and so on.
This helps debugging program's behaviors and writing manuals.
TOMOYO Linux is also applicable for educational use.
Provide per application firewall.
It is userland applications' businesses to perform pathname based access
control, but they sometimes make mistakes which are known as OS command
injection vulnerability or buffer overflow vulnerability.
TOMOYO Linux assists this access control in kernel space to reduce
the damage by restricting pathnames which each application can request.
TOMOYO Linux can perform TCP_Wrapper-like simple stateless
TCP/IP packet filtering based on IPv4/v6 address and ports.
TOMOYO Linux can restrict the list of environment variable's name
passed to execve() so that some dangerous environment variable
(e.g. LD_PRELOAD) won't be passed freely.
TOMOYO Linux also supports conditional permissions.
You can use uid/gid etc. of a process to restrict the combination of
user and accessible resources.
Provide support for multi-call binary applications without patches.
A multi-call binary (e.g. /sbin/busybox) changes behaviors according to
the invocation name (in other words, argv[0] passed to execve()).
Users specify the invocation name using symbolic links or hard links.
TOMOYO Linux allows administrators to give execute permission and define PIH
using the pathname of a symbolic link, if the combination of
the pathname of a symbolic link and the pathname of the entity pointed
by the symbolic link is registered in the policy file.
You can use symbolic links as if they are hard links.
TOMOYO Linux supports restricting the combination of
path-to-executable-or-symbolic-link and basename-of-argv[0]
so that users can't pass different argv[0]
from path-to-executable-or-symbolic-link freely.
Please be aware that some multi-call binary programs change their behaviors
according to the command line parameters (i.e. argv[1] to argv[argc - 1]).
Regarding such programs, TOMOYO Linux can't restrict behaviors by restricting
the argv[0]. But TOMOYO Linux doesn't attempt to restrict all argv[] elements
passed to execve(), because doing so will make the system too inconvenient
and frustrating to use.
Give different set of permissions to the same application.
There are some non-executable applications (e.g. Java's class files).
Such applications use the same program for executing (e.g. Java Runtime
Environment). Since TOMOYO Linux has PIH, you can give different set of
permissions for each application by separating PIH for each application.
Although TOMOYO Linux can switch context for every execve() requests,
it is preferable to be able to switch context without invoking execve().
So far, we are not providing APIs to switch context like AppArmor's
change_hat()/change_profile(). We'd like to introduce APIs to switch context
when distributors get ready to support TOMOYO Linux (in other words, after
TOMOYO Linux is merged into mainline).
Provide DMZ for remote logins.
Recently, password brute-force attacks against SSH service are increasing.
But TOMOYO Linux's PIH can provide a room for deploying DMZ.
Why password or public-key authentication is possible for only once?
Why not give normal users a chance to beat back attackers who logged in
through brute-force attacks?
You can deploy extra login authentications that the only normal user knows
how to pass.
Provide simple RBAC-like administrative task division.
TOMOYO Linux's PIH forms a tree structure.
This means that you can split one tree into several subtrees
and associate each subtree with each administrative task.
You can give each subtree necessary and sufficient permissions
for each administrative task.
You can deploy custom authentication at the entry point of each subtree
so that one administrator cannot proceed to other administrator's subtrees.
And more...
Your imagination invents new usage.
Authors:
Tetsuo Handa <[email protected]>
Toshiharu Harada <[email protected]>
Kentaro Takeda <[email protected]>
Appendix 1 - Usability features of TOMOYO Linux
TOMOYO Linux switches the context of a process whenever a process executes
a program, but there are two exceptions.
Administrator may relocate domain of a process if PIH is not meaningful for
that process (e.g. daemon programs). This exception allows administrator
restart daemon programs.
Administrator may suppress domain transition if domain transition is not
meaningful for that process (e.g. /bin/touch called from /etc/init.d/ scripts).
This exception reduces memory usage for policy.
TOMOYO Linux can apply access control over all userspace applications,
but administrator can also apply access control over only specific userspace
applications if he/she wishes so.
TOMOYO Linux supports "delayed enforcing mode" that allows administrator
interactively judge whether a request which is not defined in the policy
should be permitted or rejected.
This mode helps administrator adjust the policy after software updates.
Appendix 2 - Presentation slides
- PacSec2007: TOMOYO Linux: "A Practical Method to Understand and Protect
Your Own Linux Box"
http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf
- OLS2007: "TOMOYO Linux BoF"
http://sourceforge.jp/projects/tomoyo/document/ols2007-tomoyo-20070629.pdf
- ELC2007: "TOMOYO Linux - A Lightweight and Manageable Security System
for PC and Embedded Linux"
http://sourceforge.jp/projects/tomoyo/document/elc2007-presentation-20070418-for_linux.pdf
Quoting Tetsuo Handa ([email protected]):
> This document is intended to specify the security goal that TOMOYO Linux is
> trying to achieve, so that users can evaluate whether TOMOYO Linux will meet
> their needs, and kernel developers can evaluate whether TOMOYO Linux deserved
> to be in-tree.
>
> 1. About TOMOYO Linux
>
> Project Homepage: http://tomoyo.sourceforge.jp/index.html.en
> Project Wiki: http://elinux.org/TomoyoLinux
>
> TOMOYO Linux is a DIY tool for understanding and protecting your system.
> TOMOYO Linux policy definitions are absolutely readable to Linux users, and
> TOMOYO Linux supports unique policy learning mechanism which automatically
Are they in fact unique?
> gathers information and arranges the results as policy definitions.
> These things made it possible for users to write policy from scratch.
> Troubleshooting can be done by users.
> We put some TOMOYO Linux policy examples on our web site.
>
> http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample
>
> 2. TOMOYO Linux Security Goal
This section seems to me to be the most important one, and could really
use a little more detail.
> The TOMOYO Linux's security goal is to provide "MAC that covers practical
> requirements
This email promised me a security goal, but instead of laying out
requirements it meets, its says it meets "practical requirements".
That's really not helpful.
What kernel resources does TOMOYO authorize? All those which SELinux
does?
> for most users and keeps usable for most administrators".
> TOMOYO Linux is not a tool for security professional but for average users
> and administrators.
So your point was that your main goal is simplicity?
Ok a few things you could add:
1. Tomoyo provide no sort of information flow control.
2. TOMOYO is purely restrictive.
3. Learning mode is primary source of policy so you
depend on change of behavior to detect intruders.
4. but any intruder who attempts to do something which
the compomised sftware wouldn't have done should be
stopped and detected.
This gives a precise (though perhaps wrong as I'm guessing :) picture
of what TOMOYO can do and how it fits in with SMACK, apparmor,
capabilities, and SELinux.
thanks,
-serge
> 3. Our Approach
>
> To meet the above goal, TOMOYO Linux attempts to make the system where
> everything is prearranged in an easy-to-understand way.
>
> * Make the all subject's all access requests that will occur at least once
> during the lifetime of the kernel known in advance.
>
> * Let the administrator understand what access requests will each subject
> raise in his/her system and write policy which only allows expected and
> desirable access requests for his/her needs.
>
> Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from
> attackers exploiting vulnerabilities in applications that the system hosts.
> The threat is that an attacker can cause a vulnerable application to do
> something unexpected and undesirable. TOMOYO Linux addresses this threat by
> recording all applications' behaviors in the test environment and forcing
> all applications behave within recorded behaviors in the production environment.
>
> TOMOYO Linux has a unique concept of "process invocation history"
> (in short, PIH). The PIH is a developmental lineage of a process.
> When a process executes a program, the process creates a copy with fork() and
> replace the copy with execve().
> TOMOYO Linux appends the pathname of the executed program to the PIH of
> the replaced process, and associates process's PIH (stored in task_struct)
> with a domain.
> As a result, the context switching (a.k.a. domain transition) is unidirectional.
> This rule allows administrator distinguish and manage fine-grained context.
> Domain transition forms tree structure like a directory tree of filesystems.
> Each domain has different set of permissions that are essential for that domain.
>
> 4. Things you can do with TOMOYO Linux.
>
> Create policy from scratch.
>
> You want to use ready-made policy files supplied by somebody else
> because testing all paths needed for your usage sounds boring?
>
> OK, then you can choose other implementations that provide
> ready-made policy files, but you should check whether these files
> contain enough permissions for your usage or not. It is inevitable thing
> to test all paths needed for your usage if you want to use white listing
> access control.
>
> Also, ready-made policy files tend to contain redundant permissions
> for your usage which often leads to serious problem.
>
> TOMOYO Linux is a DIY tool for understanding and protecting your Linux box.
> TOMOYO Linux's "learning mode" will automatically generate
> policy files with necessary and sufficient permissions for you.
>
> Understand all possible requests.
>
> TOMOYO Linux reports what is happening within your Linux box.
> You can have the security of knowing that no unexpected requests arise,
> if you have tested all paths needed for your usage.
>
> Please remember, we are not saying that
> "You can have the security of knowing that no unexpected results happen".
> Although TOMOYO Linux attempts to filter the request as hard as possible,
> TOMOYO Linux can't guarantee the result.
>
> Analyze system's behavior.
>
> TOMOYO Linux resembles to /usr/bin/strace .
> TOMOYO Linux reports what programs are executed from each program and
> what files/networks are accessed by each program.
>
> You can use TOMOYO Linux for analyzing application's behavior
> if you want to know "which configuration file does this daemon read?",
> "what port numbers does this daemon require?" and so on.
>
> This helps debugging program's behaviors and writing manuals.
> TOMOYO Linux is also applicable for educational use.
>
> Provide per application firewall.
>
> It is userland applications' businesses to perform pathname based access
> control, but they sometimes make mistakes which are known as OS command
> injection vulnerability or buffer overflow vulnerability.
> TOMOYO Linux assists this access control in kernel space to reduce
> the damage by restricting pathnames which each application can request.
>
> TOMOYO Linux can perform TCP_Wrapper-like simple stateless
> TCP/IP packet filtering based on IPv4/v6 address and ports.
>
> TOMOYO Linux can restrict the list of environment variable's name
> passed to execve() so that some dangerous environment variable
> (e.g. LD_PRELOAD) won't be passed freely.
>
> TOMOYO Linux also supports conditional permissions.
> You can use uid/gid etc. of a process to restrict the combination of
> user and accessible resources.
>
> Provide support for multi-call binary applications without patches.
>
> A multi-call binary (e.g. /sbin/busybox) changes behaviors according to
> the invocation name (in other words, argv[0] passed to execve()).
> Users specify the invocation name using symbolic links or hard links.
>
> TOMOYO Linux allows administrators to give execute permission and define PIH
> using the pathname of a symbolic link, if the combination of
> the pathname of a symbolic link and the pathname of the entity pointed
> by the symbolic link is registered in the policy file.
> You can use symbolic links as if they are hard links.
>
> TOMOYO Linux supports restricting the combination of
> path-to-executable-or-symbolic-link and basename-of-argv[0]
> so that users can't pass different argv[0]
> from path-to-executable-or-symbolic-link freely.
>
> Please be aware that some multi-call binary programs change their behaviors
> according to the command line parameters (i.e. argv[1] to argv[argc - 1]).
> Regarding such programs, TOMOYO Linux can't restrict behaviors by restricting
> the argv[0]. But TOMOYO Linux doesn't attempt to restrict all argv[] elements
> passed to execve(), because doing so will make the system too inconvenient
> and frustrating to use.
>
> Give different set of permissions to the same application.
>
> There are some non-executable applications (e.g. Java's class files).
> Such applications use the same program for executing (e.g. Java Runtime
> Environment). Since TOMOYO Linux has PIH, you can give different set of
> permissions for each application by separating PIH for each application.
>
> Although TOMOYO Linux can switch context for every execve() requests,
> it is preferable to be able to switch context without invoking execve().
> So far, we are not providing APIs to switch context like AppArmor's
> change_hat()/change_profile(). We'd like to introduce APIs to switch context
> when distributors get ready to support TOMOYO Linux (in other words, after
> TOMOYO Linux is merged into mainline).
>
> Provide DMZ for remote logins.
>
> Recently, password brute-force attacks against SSH service are increasing.
> But TOMOYO Linux's PIH can provide a room for deploying DMZ.
>
> Why password or public-key authentication is possible for only once?
> Why not give normal users a chance to beat back attackers who logged in
> through brute-force attacks?
>
> You can deploy extra login authentications that the only normal user knows
> how to pass.
>
> Provide simple RBAC-like administrative task division.
>
> TOMOYO Linux's PIH forms a tree structure.
> This means that you can split one tree into several subtrees
> and associate each subtree with each administrative task.
> You can give each subtree necessary and sufficient permissions
> for each administrative task.
>
> You can deploy custom authentication at the entry point of each subtree
> so that one administrator cannot proceed to other administrator's subtrees.
>
> And more...
>
> Your imagination invents new usage.
>
>
> Authors:
> Tetsuo Handa <[email protected]>
> Toshiharu Harada <[email protected]>
> Kentaro Takeda <[email protected]>
>
>
> Appendix 1 - Usability features of TOMOYO Linux
>
> TOMOYO Linux switches the context of a process whenever a process executes
> a program, but there are two exceptions.
> Administrator may relocate domain of a process if PIH is not meaningful for
> that process (e.g. daemon programs). This exception allows administrator
> restart daemon programs.
> Administrator may suppress domain transition if domain transition is not
> meaningful for that process (e.g. /bin/touch called from /etc/init.d/ scripts).
> This exception reduces memory usage for policy.
>
> TOMOYO Linux can apply access control over all userspace applications,
> but administrator can also apply access control over only specific userspace
> applications if he/she wishes so.
>
> TOMOYO Linux supports "delayed enforcing mode" that allows administrator
> interactively judge whether a request which is not defined in the policy
> should be permitted or rejected.
> This mode helps administrator adjust the policy after software updates.
>
>
> Appendix 2 - Presentation slides
>
> - PacSec2007: TOMOYO Linux: "A Practical Method to Understand and Protect
> Your Own Linux Box"
> http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf
>
> - OLS2007: "TOMOYO Linux BoF"
> http://sourceforge.jp/projects/tomoyo/document/ols2007-tomoyo-20070629.pdf
>
> - ELC2007: "TOMOYO Linux - A Lightweight and Manageable Security System
> for PC and Embedded Linux"
> http://sourceforge.jp/projects/tomoyo/document/elc2007-presentation-20070418-for_linux.pdf
> -
> 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
Hello.
Thank you for feedback.
Serge E. Hallyn wrote:
> > TOMOYO Linux is a DIY tool for understanding and protecting your system.
> > TOMOYO Linux policy definitions are absolutely readable to Linux users, and
> > TOMOYO Linux supports unique policy learning mechanism which automatically
>
> Are they in fact unique?
>
Yes, at least we believe so.
Have you ever heard an implementation that can automatically generate PIH
and restrict the behavior based on PIH?
Adding permissions to policy is not new because there is audit2allow
that can do it. But adding domains (or PIH) to policy is new.
Here's our version of Linux security comparison table.
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
> What kernel resources does TOMOYO authorize? All those which SELinux
> does?
TOMOYO can authorize part of kernel resources which SELinux can
and part of other resources which SELinux can't.
Currently, TOMOYO can authorize
* execve() of programs.
* open() of files for reading/writing.
* creat()/link()/rename()/unlink()/symlink()/mkfifo()/mksock()/mkblock()/
mkchar()/truncate()/mkdir()/rmdir() of files and directries
that are visible to userland process's namespace.
* namespace manipulation. (i.e. mount()/umount()/pivot_root())
* TCP/IP networking operations based on IPv4/v6 addresses and port numbers.
(Need to add LSM hooks for incoming connections/packets.)
* booleans for some operations. (Part of POSIX capability and TOMOYO's
original capability.)
* signal transmissions. (Needs to add LSM hooks.)
* argv[0] passed to execve().
* environment variables' names passed to execve().
> So your point was that your main goal is simplicity?
Yes. Keep it understandable and customizable so that end users
(i.e. administrators) can configure policy for their systems.
> 1. Tomoyo provide no sort of information flow control.
Yes. TOMOYO is not intended to provide information flow control.
Controlling information flow is not the region of interest for TOMOYO.
(I'm not a security architect. I don't understand the definition and
coverage of "information flow" in security field.
I'm using "information flow" as "how information propagates".)
I think no access control can guarantee regarding information flow.
No access control can prevent attackers from leaking information
which are caused by means granted to attackers.
Even if some implementation can prevent attackers from leaking information
regarding an atomic operation, it does not guarantee that the implementation
can prevent attackers from leaking information as a whole system.
Attackers can still do nasty requests within given permissions.
But without these permissions, the system can't work properly.
So, the region of interest for TOMOYO is how to minimize means granted to
each PIH, although not all permissions TOMOYO can authorize.
> 2. TOMOYO is purely restrictive.
Excuse me. What models are there other than "restrictive"?
I'm not sure whether what TOMOYO is doing are categorized to
"restrictive" model.
> 3. Learning mode is primary source of policy so you
> depend on change of behavior to detect intruders.
>
> 4. but any intruder who attempts to do something which
> the compomised sftware wouldn't have done should be
> stopped and detected.
Yes. TOMOYO's power comes from "know all and understand what requests
can happen within this system".
Regards.
Quoting Tetsuo Handa ([email protected]):
> Hello.
>
> Thank you for feedback.
>
> Serge E. Hallyn wrote:
> > > TOMOYO Linux is a DIY tool for understanding and protecting your system.
> > > TOMOYO Linux policy definitions are absolutely readable to Linux users, and
> > > TOMOYO Linux supports unique policy learning mechanism which automatically
> >
> > Are they in fact unique?
> >
> Yes, at least we believe so.
Ok I didn't mean that as criticism, but a real question :)
Auto-learning in itself doesn't seem novel, but so you're saying it's
novel in ust how integrated it is - no mnual intervention necessary?
> Have you ever heard an implementation that can automatically generate PIH
> and restrict the behavior based on PIH?
> Adding permissions to policy is not new because there is audit2allow
> that can do it. But adding domains (or PIH) to policy is new.
Does grsec's learning mode come closer to yours? (I've never used
grsec, just got the impression it did a lot of auto-learning stuff)
> Here's our version of Linux security comparison table.
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
hey that's a nice chart. I'd link it explicitly from the doc...
> > What kernel resources does TOMOYO authorize? All those which SELinux
> > does?
> TOMOYO can authorize part of kernel resources which SELinux can
> and part of other resources which SELinux can't.
>
> Currently, TOMOYO can authorize
>
> * execve() of programs.
> * open() of files for reading/writing.
> * creat()/link()/rename()/unlink()/symlink()/mkfifo()/mksock()/mkblock()/
> mkchar()/truncate()/mkdir()/rmdir() of files and directries
> that are visible to userland process's namespace.
> * namespace manipulation. (i.e. mount()/umount()/pivot_root())
do you track mounts namespace cloning?
Well I don't see how you could without a new lsm hook :) But it seems
like something you'd need to really support this claim. Any plans of
it?
> * TCP/IP networking operations based on IPv4/v6 addresses and port numbers.
> (Need to add LSM hooks for incoming connections/packets.)
> * booleans for some operations. (Part of POSIX capability and TOMOYO's
> original capability.)
> * signal transmissions. (Needs to add LSM hooks.)
> * argv[0] passed to execve().
> * environment variables' names passed to execve().
Cool - by all means keep this list in your next version of this doc.
> > So your point was that your main goal is simplicity?
> Yes. Keep it understandable and customizable so that end users
> (i.e. administrators) can configure policy for their systems.
>
> > 1. Tomoyo provide no sort of information flow control.
> Yes. TOMOYO is not intended to provide information flow control.
> Controlling information flow is not the region of interest for TOMOYO.
> (I'm not a security architect. I don't understand the definition and
> coverage of "information flow" in security field.
> I'm using "information flow" as "how information propagates".)
Right.
No need to defend it, not everyone needs it. Just make it clear that
you don't care to support information flow control, then noone can
attack TOMOYO saying "it shouldn't be upstream bc it fails to provide
information flow control."
> I think no access control can guarantee regarding information flow.
> No access control can prevent attackers from leaking information
> which are caused by means granted to attackers.
I'd argue, but it's really not relevant right now :)
> Even if some implementation can prevent attackers from leaking information
> regarding an atomic operation, it does not guarantee that the implementation
> can prevent attackers from leaking information as a whole system.
> Attackers can still do nasty requests within given permissions.
> But without these permissions, the system can't work properly.
> So, the region of interest for TOMOYO is how to minimize means granted to
> each PIH, although not all permissions TOMOYO can authorize.
>
> > 2. TOMOYO is purely restrictive.
> Excuse me. What models are there other than "restrictive"?
capability and multi-admin can provide extra privilege to non-root
users.
> I'm not sure whether what TOMOYO is doing are categorized to
> "restrictive" model.
>
> > 3. Learning mode is primary source of policy so you
> > depend on change of behavior to detect intruders.
> >
> > 4. but any intruder who attempts to do something which
> > the compomised sftware wouldn't have done should be
> > stopped and detected.
> Yes. TOMOYO's power comes from "know all and understand what requests
> can happen within this system".
Cool.
thanks,
-serge
Hello.
Serge E. Hallyn wrote:
> Auto-learning in itself doesn't seem novel, but so you're saying it's
> novel in ust how integrated it is - no mnual intervention necessary?
You can run your system with only policy collected by learning mode.
Thus, you basically don't need manual intervention.
But since there are randomly named files (i.e. temporary files),
you pay a little time to modify policy.
The learning mode is to save time for permitting commonly accessed resources.
Administrator reviews policy collected by learning mode. Thus the readability
of policy is important so that administrator can understand what he/she is
going to allow or reject.
> Does grsec's learning mode come closer to yours? (I've never used
> grsec, just got the impression it did a lot of auto-learning stuff)
I looked at a glance. As far as I saw, it is not real-time policy generation.
It generates policy from logs like SELinux's audit2allow or AppArmor's
aa-genprof . Thus, I think grsec doesn't add domains in real-time like TOMOYO.
(I never used grsec too.)
It seems to me that grsec is designed for as fine grained access control
as SELinux's, while AppArmor and TOMOYO is designed for usability.
AppArmor's final implementation might come closer to grsec.
> > * namespace manipulation. (i.e. mount()/umount()/pivot_root())
>
> do you track mounts namespace cloning?
>
Yes. TOMOYO can recognize mount operation with the following flags.
--bind --move --remount
--make-unbindable --make-private --make-slave --make-shared
Although pathname based access control is not good at handling complicated
mount operations like http://lwn.net/Articles/159077/ , many systems don't
require such complicated ones.
Speak of bind mounts, there comes vfsmount problem.
AppArmor has been proposing patches to pass "struct vfsmount" parameter to
VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine
which pathname was requested in the bind-mounted environment.
Without the vfsmount patches, we can't calculate pathname without the risk of
AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held).
I think we should start discussing how the vfsmount patches can be merged.
I'm sad to see no response for AppArmor's posting
at http://lkml.org/lkml/2007/12/20/182 .
> Well I don't see how you could without a new lsm hook :) But it seems
> like something you'd need to really support this claim. Any plans of
> it?
I'm ready to submit patches for 2.6.24-rc6-mm1, but it seems to me that many
developers are offline. So, I'll submit patches when they come back to online.
Regards.
Quoting Tetsuo Handa ([email protected]):
> Hello.
>
>
> Serge E. Hallyn wrote:
> > Auto-learning in itself doesn't seem novel, but so you're saying it's
> > novel in ust how integrated it is - no mnual intervention necessary?
>
> You can run your system with only policy collected by learning mode.
> Thus, you basically don't need manual intervention.
> But since there are randomly named files (i.e. temporary files),
> you pay a little time to modify policy.
>
> The learning mode is to save time for permitting commonly accessed resources.
> Administrator reviews policy collected by learning mode. Thus the readability
> of policy is important so that administrator can understand what he/she is
> going to allow or reject.
>
>
> > Does grsec's learning mode come closer to yours? (I've never used
> > grsec, just got the impression it did a lot of auto-learning stuff)
> I looked at a glance. As far as I saw, it is not real-time policy generation.
> It generates policy from logs like SELinux's audit2allow or AppArmor's
> aa-genprof . Thus, I think grsec doesn't add domains in real-time like TOMOYO.
> (I never used grsec too.)
>
> It seems to me that grsec is designed for as fine grained access control
> as SELinux's, while AppArmor and TOMOYO is designed for usability.
> AppArmor's final implementation might come closer to grsec.
>
>
> > > * namespace manipulation. (i.e. mount()/umount()/pivot_root())
> >
> > do you track mounts namespace cloning?
> >
> Yes. TOMOYO can recognize mount operation with the following flags.
>
> --bind --move --remount
> --make-unbindable --make-private --make-slave --make-shared
No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS). Without
tracking those, it seems like a convoluted sequence of mounting,
unmonting, and mount sharing and unsharing could potentially confuse
your policy or your admins...
I haven't fully thought it through. But at least if an admin makes a
policy update with an expectation that all processes have the same mount
trees the result could be unsafe.
> Although pathname based access control is not good at handling complicated
> mount operations like http://lwn.net/Articles/159077/ , many systems don't
> require such complicated ones.
Don't require it, but that statement is only meaningful if you then
prevent it, no?
> Speak of bind mounts, there comes vfsmount problem.
> AppArmor has been proposing patches to pass "struct vfsmount" parameter to
> VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine
> which pathname was requested in the bind-mounted environment.
> Without the vfsmount patches, we can't calculate pathname without the risk of
> AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held).
> I think we should start discussing how the vfsmount patches can be merged.
> I'm sad to see no response for AppArmor's posting
> at http://lkml.org/lkml/2007/12/20/182 .
If the patches solve your problem, and you respond saying "TOMOYO needs
these patches too", it just might get the thread going.
> > Well I don't see how you could without a new lsm hook :) But it seems
> > like something you'd need to really support this claim. Any plans of
> > it?
> I'm ready to submit patches for 2.6.24-rc6-mm1, but it seems to me that many
> developers are offline. So, I'll submit patches when they come back to online.
Sounds good.
thanks,
-serge
On Fri, 28 Dec 2007 23:32:09 +0900, Tetsuo Handa said:
> You can run your system with only policy collected by learning mode.
> Thus, you basically don't need manual intervention.
> But since there are randomly named files (i.e. temporary files),
> you pay a little time to modify policy.
>
> The learning mode is to save time for permitting commonly accessed resources.
> Administrator reviews policy collected by learning mode. Thus the readability
> of policy is important so that administrator can understand what he/she is
> going to allow or reject.
Please make a *big* notation someplace that "learning mode" is quite likely to
*not* produce a totally correct policy. In particular, it won't build rules for
infrequently used code paths (such as error handling) unless you find a way to
exercise those paths while in learning mode.
Particularly fun - when learning mode doesn't create an entry for the logfile
for I/O errors. Then when one actually happens, you have no idea what it was...
Hello.
Serge E. Hallyn wrote:
> > > > * namespace manipulation. (i.e. mount()/umount()/pivot_root())
> > >
> > > do you track mounts namespace cloning?
> > >
> > Yes. TOMOYO can recognize mount operation with the following flags.
> >
> > --bind --move --remount
> > --make-unbindable --make-private --make-slave --make-shared
>
> No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS). Without
> tracking those, it seems like a convoluted sequence of mounting,
> unmonting, and mount sharing and unsharing could potentially confuse
> your policy or your admins...
Oh, I see. TOMOYO doesn't track clone() and unshare().
> I haven't fully thought it through. But at least if an admin makes a
> policy update with an expectation that all processes have the same mount
> trees the result could be unsafe.
TOMOYO doesn't expect that all processes have the same mount trees.
But TOMOYO expects that the mount trees won't change unless one of mount()/
umount()/pivot_root() are called.
Does a process get different mount trees by just calling clone() or unshare()?
My understanding is that clone() or unshare() disables propergation of
mount tree changes when somebody calls mount() or umount() or pivot_root().
> > Speak of bind mounts, there comes vfsmount problem.
> > AppArmor has been proposing patches to pass "struct vfsmount" parameter to
> > VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine
> > which pathname was requested in the bind-mounted environment.
> > Without the vfsmount patches, we can't calculate pathname without the risk of
> > AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held).
> > I think we should start discussing how the vfsmount patches can be merged.
> > I'm sad to see no response for AppArmor's posting
> > at http://lkml.org/lkml/2007/12/20/182 .
>
> If the patches solve your problem, and you respond saying "TOMOYO needs
> these patches too", it just might get the thread going.
>
I'll say it when I submit patches.
Regards.
On Fri 2007-12-28 12:23:51, [email protected] wrote:
> On Fri, 28 Dec 2007 23:32:09 +0900, Tetsuo Handa said:
>
> > You can run your system with only policy collected by learning mode.
> > Thus, you basically don't need manual intervention.
> > But since there are randomly named files (i.e. temporary files),
> > you pay a little time to modify policy.
> >
> > The learning mode is to save time for permitting commonly accessed resources.
> > Administrator reviews policy collected by learning mode. Thus the readability
> > of policy is important so that administrator can understand what he/she is
> > going to allow or reject.
>
> Please make a *big* notation someplace that "learning mode" is quite likely to
> *not* produce a totally correct policy. In particular, it won't build rules for
> infrequently used code paths (such as error handling) unless you find a way to
> exercise those paths while in learning mode.
>
> Particularly fun - when learning mode doesn't create an entry for the logfile
> for I/O errors. Then when one actually happens, you have no idea what it was...
Yes... if you disallow access to /etc/nologin (or do something
similary stupid) you can even introduce security hole...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hello.
[email protected] wrote:
> Please make a *big* notation someplace that "learning mode" is quite likely to
> *not* produce a totally correct policy. In particular, it won't build rules for
> infrequently used code paths (such as error handling) unless you find a way to
> exercise those paths while in learning mode.
Use of "learning mode" is independent from "correct policy".
The "learning mode" merely takes your duty of appending permissions to policy.
We can develop and share procedures for how to exercise infrequently used code
paths, like how to confirm that your SMTP service won't relay spams.
This problem is nothing but "developing and sharing procedures for how to
exercise infrequently used code paths" has not started yet.
By the way, what is the definition of "correct policy"?
The definition of "correct policy" depends on the user.
Some users may think that
"A ready-made policy is better than a manually-made policy
even if the ready-made policy contains unused/unneeded permissions.
Being unable to handle infrequently used code paths is worse than
leaving a room for not knowing/understanding what can happen."
but other users may think that
"A manually-made policy is better than a ready-made policy
even if the manually-made policy lacks permissions for infrequently
used code paths.
Leaving a room for not knowing/understanding what can happen is worse than
being unable to handle infrequently used code paths."
You can use "permissive mode" to adjust and confirm your policy
before you use "enforcing mode".
You can also use "delayed enforcing mode" that allows an administrator
handle infrequently used code paths without once rejecting those code paths.
If the policy is not correct, it is the person's fault who enforced that policy
without confirming that that policy is suitable for his/her system.
Since the definition of "correct policy" is not a globally agreed word,
I think we can't say that "learning mode unlikely produces correct policy".
Thanks.
On Sun, 30 Dec 2007 14:29:50 +0900, Tetsuo Handa said:
> Use of "learning mode" is independent from "correct policy".
My point *exactly*.
> The "learning mode" merely takes your duty of appending permissions to policy.
> We can develop and share procedures for how to exercise infrequently used code
> paths, like how to confirm that your SMTP service won't relay spams.
> This problem is nothing but "developing and sharing procedures for how to
> exercise infrequently used code paths" has not started yet.
And I don't have an issue with the concept that you let a "learning mode"
develop 95% of the policy for you - as long as you make clear that you *do*
need to do some work to ensure all code paths are tested, or otherwise verify
that the generated policy is in fact correct. For instance, semantic analysis
of the program source can identify what directories a program *should* create
files in - if some directories aren't in fact listed in the policy, they need
to be added. If the actual learned policy includes directories that shouldn't
have been learned, you've got a *bigger* problem. And yes, I have worked with
more than one case where a "benchline" measurement of a system happened to
include an actual intrusion....
> By the way, what is the definition of "correct policy"?
> The definition of "correct policy" depends on the user.
>
> Some users may think that
>
> "A ready-made policy is better than a manually-made policy
> even if the ready-made policy contains unused/unneeded permissions.
> Being unable to handle infrequently used code paths is worse than
> leaving a room for not knowing/understanding what can happen."
>
> but other users may think that
>
> "A manually-made policy is better than a ready-made policy
> even if the manually-made policy lacks permissions for infrequently
> used code paths.
> Leaving a room for not knowing/understanding what can happen is worse than
> being unable to handle infrequently used code paths."
Neither.
Policy *correctness* is a measure of how well the policy allows those
events that should properly happen, and rejects those events that should not
happen. What you discuss here is what the relative impact of various *errors*
in the policy - basically, false-negative versus false-positive identification
of policy-violating activity. Your first example says that it's preferable
to false-negative and fail to flag a violation, your second that it's
preferable to false-positive and flag something that should have been allowed.
In neither case are you actually talking about *correct* policy - which
would *properly* describe the desired behavior. Note that how the policy
was *created* does not affect the *actual* correctness of the policy - it's
quite possible to create both correct and incorrect policies via both
manual and ready-made methods.
The *true* security question is: What method minimizes your *total* cost of
both developing the policy and dealing with *both* the false positives and
negatives of a possibly incorrect policy?
> Since the definition of "correct policy" is not a globally agreed word,
> I think we can't say that "learning mode unlikely produces correct policy".
I'm pretty sure that most of the security community agrees on what "correct"
means - the disagreement is in the most cost-effective way to *create* one.
Notice that I never said "learning mode is *unlikely* to produce correct policy".
What I said was "Learning mode *may* produce a correct policy, but there is a
non-zero probability that needed things will remain unlearned unless care is
taken to ensure they are learned".
And I've been in this industry long enough to have *many* teeth marks where
I've been bitten by very small but non-zero probabilities.... :)
Quoting Tetsuo Handa ([email protected]):
> Hello.
>
> Serge E. Hallyn wrote:
> > > > > * namespace manipulation. (i.e. mount()/umount()/pivot_root())
> > > >
> > > > do you track mounts namespace cloning?
> > > >
> > > Yes. TOMOYO can recognize mount operation with the following flags.
> > >
> > > --bind --move --remount
> > > --make-unbindable --make-private --make-slave --make-shared
> >
> > No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS). Without
> > tracking those, it seems like a convoluted sequence of mounting,
> > unmonting, and mount sharing and unsharing could potentially confuse
> > your policy or your admins...
> Oh, I see. TOMOYO doesn't track clone() and unshare().
>
> > I haven't fully thought it through. But at least if an admin makes a
> > policy update with an expectation that all processes have the same mount
> > trees the result could be unsafe.
> TOMOYO doesn't expect that all processes have the same mount trees.
> But TOMOYO expects that the mount trees won't change unless one of mount()/
> umount()/pivot_root() are called.
> Does a process get different mount trees by just calling clone() or unshare()?
> My understanding is that clone() or unshare() disables propergation of
> mount tree changes when somebody calls mount() or umount() or pivot_root().
Yes, with further propagation rules possible.
> > > Speak of bind mounts, there comes vfsmount problem.
> > > AppArmor has been proposing patches to pass "struct vfsmount" parameter to
> > > VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine
> > > which pathname was requested in the bind-mounted environment.
> > > Without the vfsmount patches, we can't calculate pathname without the risk of
> > > AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held).
> > > I think we should start discussing how the vfsmount patches can be merged.
> > > I'm sad to see no response for AppArmor's posting
> > > at http://lkml.org/lkml/2007/12/20/182 .
> >
> > If the patches solve your problem, and you respond saying "TOMOYO needs
> > these patches too", it just might get the thread going.
> >
> I'll say it when I submit patches.
>
> Regards.
Hello.
Serge E. Hallyn wrote:
> > Does a process get different mount trees by just calling clone() or unshare()?
> > My understanding is that clone() or unshare() disables propergation of
> > mount tree changes when somebody calls mount() or umount() or pivot_root().
>
> Yes, with further propagation rules possible.
>
Excuse me. To which statement did you say "yes"?
Does clone() or unshare() change visible directories without
calling following mount()/umount()/pivot_root()?
Regards.
--- [email protected] wrote:
> I'm pretty sure that most of the security community agrees on what "correct"
> means - the disagreement is in the most cost-effective way to *create* one.
Struth. (I'm practicing my Australian, it's gotten rusty)
I say that the the only rational way to create a policy is to
decide what you want the system to do and create your policy
based on that. I think that calling something that does nothing
more than enforce existing behavior without thought on what the
behavior ought to be a "policy" does disservice to the entire
security community. I realize that I'm in the minority on this
one. Oh well.
Casey Schaufler
[email protected]
Quoting Tetsuo Handa ([email protected]):
> Hello.
>
> Serge E. Hallyn wrote:
> > > Does a process get different mount trees by just calling clone() or unshare()?
> > > My understanding is that clone() or unshare() disables propergation of
> > > mount tree changes when somebody calls mount() or umount() or pivot_root().
> >
> > Yes, with further propagation rules possible.
> >
> Excuse me. To which statement did you say "yes"?
Sorry, "yes your understanding was correct."
> Does clone() or unshare() change visible directories without
> calling following mount()/umount()/pivot_root()?
>
> Regards.
> -
> 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