![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Contents †
What is TOMOYO Linux? †Overview †TOMOYO Linux is a MAC (Mandatory Access Control) implementation for Linux. It was developed by NTT DATA CORPORATION, Japan and is available under the GPL license. TOMOYO Linux consists of patch files to vanilla kernel and userland tools. Patch files are provided for both 2.4 and 2.6. For the user's convenience, various binary packages are also available. TOMOYO Linux at KernelTrap †TOMOYO Linux at Embedded Linux †TOMOYO Linux at CELF †The code †How is TOMOYO Linux different from SELinux and AppArmor? †Secure OS Comparison At a Glance †url for this section: http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison I'm trying to make a fair and precise comparison chart here. Suggestions and comments would be greatly appreciated. Please send your feedback to haradats_at_nttdata.co.jp. Thank you.
Comparison by other projects †Policy learning feature †The most distinguishable feature of TOMOYO Linux is its *real-time* policy learning feature. SELinux has two modes of "permissive" and "enforcing", TOMOYO Linux has "learning" mode in addition to those two modes. In learning modes, TOMOYO Linux kernel generates definitions of domains and ACL for each domain fully automatically. This policy learning functionality covers from the system boot to shutdown. Readable and understandable policy †TOMOYO Linux is so called "pathname-based" MAC. Which means policy is described in terms of path names. TOMOYO Linux policy is in plain text format and quite Linux user friendly. See the examples. http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample Fine grain domain definition †In SELinux, domains have to be defined and most domain corresponds to a set of programs. In AppArmor, there's no concept of domain and "profile" is a unit of the policy. Profile corresponds to a program (with path name) like apache. In TOMOYO Linux, domain is a string of process invocation history (or call chains). The base of domain is "<kernel>" and domain of /sbin/init is "<kernel> /sbin/init". The child process /foo/bar which is a child of "<kernel> /sbin/init" will be "<kernel> /sbin/init /foo/bar". TOMOYO Linux defines and manages domain according to this rule, so users don't have to define them and name them. Does the TOMOYO security mechanism add any overheads to the executing processes? †Security costs and no MAC system can be exceptions. Roughly speaking, TOMOYO Linux has a little lighter overheads compared to SELinux. Benchmark †Environment †LMBench (3.0-a8) output of TOMOYO Linux (version 1.5.1). (CPU: Intel Core 2 Duo 6400 2.13GHz, RAM 2GB, CentOS 5, 2.6.23.1 Kernel) Graph † Data †
CE Linux forum are trying to gathering data. †What are the main objections that people have against pathname-based solutions like TOMOYO Linux? †
How does TOMOYO Linux overcome these so-called "limitations"? †Overview †Detail †Not all objects have pathnames. †What TOMOYO Linux does is use pathnames that are accessible via filesystem's mount tree. TOMOYO Linux does not deny labeling on objects that are not accessible via filesystem's mount tree. Although it is not implemented yet; it's a future work. I need to reduce my burden of catching up with the latest kernels. if I execute "ln /etc/shadow /tmp/shadow", /etc/shadow is not protected. †Suppose an administrator wants to forbid access to /etc/shadow. Regarding pathname based access control, one can access to /etc/shadow by creating hardlinks to /tmp/shadow. Regarding label based access control, one can't access to /etc/shadow by creating hardlinks to /tmp/shadow because /tmp/shadow keeps the same label with /etc/shadow. TOMOYO Linux forbids creating hardlinks of /etc/shadow to /tmp/shadow from the beginning. TOMOYO Linux handles pathnames carefully. TOMOYO Linux checks for both link-source and link-target together. One can't do "ln /etc/shadow /tmp/shadow" unless the administrator explicitly gives "allow_link /etc/shadow /tmp/shadow" permission. The essential combinations of link-source and link-target are not infinite and TOMOYO Linux allows only essential combinations to minimize the risk of bypassing pathname based access control. Please remember, TOMOYO Linux is white-listing and system-wide access control. It's black-listing's approach that denies access to /etc/shadow but allows access to /tmp/shadow. White-listing approach will not allow access to /tmp/shadow unless explicitly given. TOMOYO Linux can apply access control including login session. One can't do "ln /etc/shadow /tmp/shadow" unless the administrator explicitly give "allow_link /etc/shadow /tmp/shadow" permission. if I rename files, what will you do? †Suppose an administrator wants to forbid access to /etc/shadow. Regarding pathname based access control, one can access to /etc/shadow by renaming to /tmp/shadow. Regarding label based access control, one can't access to /etc/shadow by renaming to /tmp/shadow because /tmp/shadow keeps the same label as /etc/shadow. Thus, TOMOYO Linux forbids renaming /etc/shadow to /tmp/shadow from the beginning. TOMOYO Linux checks for both old-name and new-name together. One can't do "mv /etc/shadow /tmp/shadow" unless the administrator explicitly gives "allow_rename /etc/shadow /tmp/shadow" permission. The essential combinations of old-name and new-name are not infinite and TOMOYO Linux allows only essential combinations to minimize the risk of bypassing pathname based access control. You might worry that /etc/shadow can be renamed to /tmp/shadow between the moment the kernel got "dentry" and "vfsmount" from /etc/shadow and the moment TOMOYO Linux obtains a pathname from "dentry" and "vfsmount". Yes, the possibility is not zero. But TOMOYO Linux is white-listing and system-wide access control. TOMOYO Linux allows only essential combinations of renaming requests. Thus, renaming /etc/shadow to /tmp/shadow will not happen unless the administrator explicitly gives "allow_rename /etc/shadow /tmp/shadow" permission. how about symbolic links? †This is because you are using pathnames before resolving symbolic links for access control, and this is a problem of performing access control at userland level. What TOMOYO Linux deals is performing access control at kernel level. In the kernel, a pathname is converted into "dentry" and "vfsmount". And one can get a pathname without symbolic links, ".", "..", "//" by traversing "dentry" and "vfsmount" upward. Thus, even if one requests access to /tmp/shadow , TOMOYO Linux will think that /etc/shadow is requested. Therefore, TOMOYO Linux will not allow access to /etc/shadow using a symbolic link /tmp/shadow . what do you do with files with randomly generated names. †Most temporary files have some prefix. Thus, the administrator seldom needs to grant whole permission like /tmp/*. If there is no prefix, it is easy to modify the source code to use prefix. Also, you will be able to switch the location of temporary files using environment variables like TMP/TEMP and/or config files of application to e.g. ~/tmp/ directory. any protection for namespace manipulation? †a) TOMOYO Linux checks combination of mount_device, mount_point, filesystems for mount operation. Thus, one can't do "mount --bind /etc/ /tmp/" unless the administrator explicitly give "allow_mount /etc/ /tmp/ --bind 0" permission. b) TOMOYO Linux checks combination of old_root and new_root for pivot_root() operation (although pivot_root() is seldom used after /sbin/init starts). Thus, one can't do "pivot_root / /tmp/" unless the administrator explicitly give "allow_pivot_root / /tmp/" permission. c) Even if each process can have different namespace, it is restricted by mount()/pivot_root() checking. Thus, one can't freely create his/her own namespace. d) TOMOYO Linux uses absolute pathname that is not affected by chroot(). Pathnames derived by traversing upward up to the root of process's namespace are used in TOMOYO Linux. It is not a process's root directory. Thus, permissions are given using pathnames starting from outside the chroot jail. don't you care for ownership information at all? †Yes, it is true. But there is no rule that pathname-based access control must not use anything but pathname. In fact, TOMOYO Linux allows the administrator use inode's uid/gid/ino information in addition to pathnames. LSM hook functions are not receiving vfsmount parameter. †Since vfsmount is not added to LSM hook functions yet, the development of TOMOYO Linux 1.7.x (non-LSM version of TOMOYO Linux which can coexist with SELinux and AppArmor) has been continued. http://tomoyo.sourceforge.jp/1.7/ How has the response been to TOMOYO Linux's RFC on LKML? †"TOMOYO Linux has only recently surfaced on the wider mailing lists; its reception has not been entirely friendly." (Linux Weather Forecast --- Ouch!) 1st (13 Jun 2007) †The very first patch. The patch set were not following "SubmittingPatches" guideline.
Quite naturally, seldom comments were received. 2nd (24 Aug 2007) †Posted on 24 August. Summer vacation season and it was just before Kernel Summit. Only a few comments were received.
3rd (02 Oct 2007) †
4th (11 Oct 2007) †
5th (17 Nov 2007) †
TOMOYO Linux Security Goal (25 Dec, 2007) (thread) †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. 6th (8 Jan 2008) †
7th (4 Apr 2008) †
8th (1 May 2008) †
9th (24 Sep, 2008) †10th (9 Oct, 2008) †11th (20 Oct, 2008) †12th (4 Nov, 2008) †13th (21 Nov, 2008) †14th (1 Jan, 2009) †
15th (5 Feb, 2009) †
Links † |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
lmbench2.png
lmbench.png
