> 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 <penguin-kernel@I-love.SAKURA.ne.jp>
> Toshiharu Harada <haradats@nttdata.co.jp>
> Kentaro Takeda <takedakn@nttdata.co.jp>
>
>
> 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...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to
majordomo@vger.kernel.org
> More majordomo info at
http://vger.kernel.org/majordomo-info.html
