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_gmail.com. Thank you. :)

SELinuxSmackAppArmorTOMOYO Linux
MaintainerStephen Smalley, James Morris, Eric ParisCasey SchauflerJohn JohansenTetsuo Handa, Kentaro Takeda
Label/Pathnamelabelpathname
Mainline Status2.6.0 and later2.6.25 and later2.6.36 and later2.6.30 and later
Overview
Overviewimplementation of the research project and architecture, Flask"Simplified Mandatory Access Control Kernel"Novell had bought the company formerly known as Immunix and ported the technology to SUSE as AppArmor?. open source version is also availabledeveloped solely by NTT DATA and was open sourced in 2005
Security GoalAppArmor Security GoalTOMOYO Linux Security Goal
Developed byNSA, Red Hat, Tresys, HP, IBM, TCS etc.Casey SchauflerImmunix, NovellNTT DATA CORPORATION
Supported by(mainlined)Casey SchauflerCanonicalproject
ISO image for Live CDFedoraN/AUbuntuUbuntu/CentOS LiveCD with TOMOYO kernel
Status
CC CertificationEAL4+ CAPP,LSPP
DistributionFedora, Hardened Gentoo, RedHat, Debian, Engarde, Ubuntu etc.SUSE, Ubuntu, Mandriva, OpenSuSETurbolinux 11 Server, Mandriva, Ubuntu, Debian
Functionality
MAC modepermissive domainssystem globalper programper domain(=program with call chain)
MAC objects"all access must be explicitly granted"you specify"only confines processes that the AppArmor? policy says it should confine"same as SELinux
MAC Coveragefile, network(secmark, NetLabel?, labeled IPSEC), capabilities, local IPC, descriptor inheritance and transfer, memory protectionsfile, network(NetLabel?)file (for upstream version)file (for upstream version)
MLS supportyesyesnono
RBAC supportyesnonono
DBMS cooperationSEPostgreSQL
BusyBox support (for embedded)sebusybox projectbuilt in
KioskFedora Kiosk
CBLFS (Community Driven BLFS)N/AN/AN/ATOMOYO@CBLFS
Requirements
Filesystem requirementsxattr aware for per an inode access control, none for per a mount access controlxattr awarenonenone
Userland program modifications(mainlined)requiredunneeded
Policy
Domain definitionmanualmanualmanualautomatic (customizable)
Policy development styledistributed(reference policy) + customize policyfull customizedistributed + customizelearning + customize
Policy generationby utility (audit2allow, SELinux Policy IDE, SEEdit)user - hand - and an editorby utility (genprof) and an editorby "learning" mode (realtime in Kernel)
Policy ServerSELinux policy management infrastructureN/AN/AN/A
Interactive policy addingby tool (aa-genprof)by tool (ccs-queryd)
Centerlized policy management systemreference policy (policy by "maintainers and contributors")N/Aprofiles are supplied as packagesN/A (policy by "local system administrator")
Information Resource
What's new?SELinux NewsTOMOYO Linux news
TutorialSELinux for SysAdminlinux.conf.au 2008 slidesIntroduction to AppArmor - Ubuntu ForumsKickstart CentOS 5
Project FAQSELinux FAQ, Fedora SELinux FAQ, User Resources - SELinux Wiki(White Paper)AppArmor FAQTOMOYO Linux FAQ
ForumsDebugging AppArmorOpen Discussion
Mailing ListsSELinux Mailing ListsN/AAppArmor Mailing Listtomoyo-users-en
IRCirc.freenode.net #selinuxirc.oftc.net #apparmorN/A
Supported kernel2.6(LSM)2.6(LSM)2.6(LSM)2.6(LSM/original) and 2.4
WikiSELinux WikiAppArmor - Ubuntu WikiTOMOYO Linux Wiki
BookSELinux by Example (Frank Mayer et al, Prentice Hall, 2006)The world of TOMOYO Linux

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

lmbench2.png

Data

BaseTOMOYO 1.5.1Overhead
null I/O0.130.13-1%
stat1.441.42-1%
open/close2.054.0196%
0KB create85.04123.6345%
0KB delete76.0694.8625%
fork131.17130.23-1%
execve386.52403.314%
Simple stat1.441.42-1%
Simple fstat0.310.31-1%
sh1291.161344.284%
pipe6.676.761%
AF_UNIX8.389.149%
UDP10.6311.155%
RPC/UDP14.0915.278%
TCP13.9814.242%
RPC/TCP17.4718.204%
  • TOMOYO Linux does not impose hooks for 'read'/'write', so they are not effected.
  • Noticeable impacts exist for 'open', 'create' and 'unlink' syscalls.
  • Process generation is not very affected.

CE Linux forum are trying to gathering data.

What are the main objections that people have against pathname-based solutions like TOMOYO Linux?

  1. Not all objects have pathnames.
  2. Pathname based access control is bypassed by creating hard links.
  3. if I execute "ln /etc/shadow /tmp/shadow", /etc/shadow is not protected.
  4. if I rename files, what will you do?
  5. how about symbolic links?
  6. what do you do with files with randomly generated names.
  7. any protection for namespace manipulation?
  8. don't you care for ownership information at all?
  9. LSM hook functions are not receiving vfsmount parameter.

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!)

"TOMOYO Linux is a mandatory access control framework similar to AppArmor?. Like AppArmor?, it has been criticized for its use of pathnames and (to some) simplistic approach to security." (Linux Weather Forecast)

1st (13 Jun 2007)

The very first patch. The patch set were not following "SubmittingPatches?" guideline.

  • patch set was not checkpatch safe.
  • patch was not inlined.
  • patch for stable version instead of current git tree.

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.

  • Kyle Moffett has pointed $NEW_RANDOM_ABUSE_OF_PROCFS and $PATH_BASED_LSM_ISSUES.

3rd (02 Oct 2007)

  • Basically reposting of the 2nd one.
  • $NEW_RANDOM_ABUSE_OF_PROCS was cleaned in this version.

4th (11 Oct 2007)

  • Use "struct mutex" instead of "struct semaphore".
  • Discarded original singly linked list code and re-implement with standard RCU list.
  • This time, patch for LSM extension is excluded.

5th (17 Nov 2007)

  • Avoid namespace_sem deadlock.
  • Added capabilities support.
  • Avoid rcu_read_lock() by inserting mb() when appending to list.
  • Don't send access logs to auditing system.
  • Made patches against latest -mm tree.

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)

  • Added security goal document. (Documentation/TOMOYO.txt)
  • Added environment variable name control functionality.

7th (4 Apr 2008)

  • Since "Pass 'struct vfsmount' to LSM" problem remains unresolved, non-LSM version was posted.
  • Added execute handler functionality.

8th (1 May 2008)

  • Location to insert new LSM hooks were inappropriate.
  • security_path_open() and security_path_uselib() were redundant since security_dentry_open() is available.
  • But some hooks for TOMOYO's permission checks are still missing.

9th (24 Sep, 2008)

10th (9 Oct, 2008)

11th (20 Oct, 2008)

12th (4 Nov, 2008)

13th (21 Nov, 2008)

14th (1 Jan, 2009)

  • Reposted because security_path_*() was added to 2.6.28-git4 on 1st, January.
  • Asked to get an ACK for introducing d_realpath().
  • Asked to get an ACK for introducing singly linked list.
  • Adding in_execve flag to task_struct is pending.

15th (5 Feb, 2009)

  • Removed d_realpath().
  • Removed singly linked list.
  • Adding in_execve flag to task_struct was agreed.
  • Merged into security-testing-2.6.git tree on 12th, February.
  • Merged into linux-next.git tree on 13th, February.
  • Merged into linux-2.6.git tree on 27th, March.
  • Included in linux-2.6.30-rc1 on 8th, April.
  • Included in linux-2.6.30 on 10th, June.

Links


添付ファイル: filelmbench2.png 1720件 [詳細] filelmbench.png 1039件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2011-10-01 (土) 00:48:44 (2185d)