Hello. In TOMOYO 1.7.0 , I reviewed structure of TOMOYO 1.6.x and made functionality enhancements based on experience with Android and feedbacks obtained from TOMOYO 2.2.0 . Since the policy syntax of 1.7.0 is different from that of 1.6.x , 1.7.x is not compatible with 1.6.x . Regarding 1.6.x , hereafter I won't make functionality enhancements. Bug fix support is continued. Therefore, those who are using 1.6.x needn't to upgrade to 1.7.x . List of changes: (1) Garbage collector support was introduced. Until now, the memory used for remembering policy (or access control rules) was not released after the policy was deleted. In TOMOYO 1.7.0 , a garbage collector support was added. Hereafter, the memory is automatically released when the policy was deleted. (2) Longer pathname support was introduced. Until now, the max length of a word was 4000 bytes and the max length of a line was 8192 bytes. Therefore, access requests with pathnames which exceeds 4000 bytes had been rejected in enforcing mode. In TOMOYO 1.7.0 , the max length of a word (except argv[]/envp[] and domainnames) and the max length of a line became 128 kilo bytes (which is the max amount of memory kmalloc() can allocate). (3) More flexibly configurable profile was introduced. Until now, the granularity of access control levels was in units of "category" (e.g. "files", "networks"). In TOMOYO 1.7.0 , the granularity of access control levels ("disabled mode", "learning mode", "permissive mode", "enforcing mode") and auditing mode (whether access granted logs and rejected logs should be generated or not) are in units of "an item in a category" (e.g. "executing programs", "opening files", "creating directories", "connecting TCP sockets"). Verbose mode (whether warning messages should be printed or not) became separately configurable for each access control level. Conditions which should be automatically learned in "learning mode" became configurable. An example configuration of profile is attached at the bottom of this posting. (4) File's attributes checking was reinforced. You can control DAC's permission when creating files, directories, FIFOs, Unix domain sockets. You can control both DAC's permission and device major/minor numbers when creating block/character device files. allow_create file_to_be_created create_mode allow_mkdir directory_to_be_created create_mode allow_mkfifo fifo_to_be_created create_mode allow_mksock unix_domain_socket_to_be_created create_mode allow_mkblock block_device_to_be_created create_mode major_number minor_number allow_mkchar block_device_to_be_created create_mode major_number minor_number You can restrict changing DAC's permission and owner/group IDs. allow_chmod path_to_be_mode_changed chmod_mode allow_chown path_to_be_owner_changed user_id allow_chgrp path_to_be_group_changed group_id With these reinforcements, you can forbid (for example) creation of device files with unexpected attributes (e.g. /dev/null with char-1-5 attributes), you can forbid setting setuid/setgid bits on programs like /bin/sh , you can forbid setting executable bit on files inside user's home directories. You can restrict namespace manipulation operations in units of a domain. allow_mount path_to_device path_to_mountpoint filesystem_type flags allow_unmount path_to_unmount allow_chroot new_root_directory allow_pivot_root new_root old_root Other directives shown below are unchanged. allow_symlink symlink_to_be_created allow_link old_path new_path allow_rename old_path new_path allow_ioctl path_to_be_io_controlled cmd_number allow_read/write path_to_be_opened_for_reading_and_writing allow_execute program_to_be_executed allow_read path_to_be_opened_for_reading allow_write path_to_be_opened_for_writing allow_unlink path_to_be_deleted allow_rmdir directory_to_be_deleted allow_truncate file_to_be_truncated allow_rewrite file_to_be_rewritten (5) Number grouping directive "number_group" was introduced. Until now, there were only "path_group" directive which groups pathnames and "address_group" directive which groups IP addresses. In TOMOYO 1.7.0 , "number_group" directive which groups numeric values was added. You can now restrict numeric parameters such as DAC's permission and owner/group IDs. But sometimes it is difficult to describe acceptable ranges in a simple value range format. For example you don't want to repeat like allow_create /tmp/file 0640 allow_create /tmp/file 0660 when you want to allow either 0640 or 0660 . In that case, you can avoid repetition by defining a number group number_group TMP_FILE_CREATE_MODES 0640 number_group TMP_FILE_CREATE_MODES 0660 in the exception policy and allow_create /tmp/file @TMP_FILE_CREATE_MODES in the domain policy. The "number_group" directive is also useful when you use TOMOYO on Android. ( http://sourceforge.jp/projects/tomoyo/docs/Part2_CELF_Android.pdf ) TOMOYO supports UID based access restrictions. Thus, you can restrict like below permission. allow_execute /bin/sh if task.uid!=0 In Android environment, a unique UID is assigned for each application, but the UID which an application will use is not known until the installation time of the application. As a result, you cannot determine ????? part of below permission since you can't know ????? part beforehand. allow_read /data/data/package1/\* if task.uid=????? But with "number_group" directive, you can create the domain policy like allow_read /data/data/package1/\* if task.uid=@PACKAGE1_DATA_READERS beforehand and append a line like number_group PACKAGE1_DATA_READERS 10000 to the exception policy after the ????? part is determined. Therefore, it becomes easier for application developers to distribute applications with policy for the applications together. (6) "alias" directive and "allow_argv0" directive were removed. Until now, "allow_execute" directive was checking execute permission of the dereferenced pathname, unless explicitly defined using "alias" directive, if the requested pathname is a symlink. In TOMOYO 1.7.0 , "allow_execute" directive checks execute permission of the symlink's pathname if the requested pathname is a symlink. Also, TOMOYO checks the dereferenced pathname using "exec.realpath" variable and the invocation name using "exec.argv[0]" variable in "if" clause of "allow_execute" directive. For example, if /sbin/pidof is a symlink to /sbin/killall5 , the permission to execute /sbin/pidof is defined as below. allow_execute /sbin/pidof if exec.realpath="/sbin/killall5" exec.argv[0]="/sbin/pidof" (7) Installation time became shorter. Until now, generating initial policy took several minutes because we had to scan the entire disk for symlinks in order to generate "alias" directives. In TOMOYO 1.7.0, generating initial policy completes within a few seconds because we no longer need to scan the entire disk for symlinks. (8) The system policy was removed. The "deny_autobind" directive (which prevents specific local ports from being assigned by "bind() with port number = 0" or "connect() without bind()") was moved to the exception policy. Other directives were moved to the domain policy. (9) The syaoran filesystem was removed. In TOMOYO 1.7.0 , you can restrict device attributes using "allow_mkblock" and "allow_mkchar" directives, you can restrict mode changes using "allow_chmod" directive, you can restrict owner/group IDs changes using "allow_chown" and "allow_chgrp" directives. This means that there is no need to restrict "filename and device attributes" pairing and "change of mode and owner/group IDs" at the filesystem layer. Thus, I removed syaoran filesystem (which restricts these parameters at the filesystem layer) support. (10) Use of exclusive section was reduced. Until now, TOMOYO had own list for detecting memory leak. But a memory leak detection mechanism ( CONFIG_DEBUG_KMEMLEAK ) was merged into kernel 2.6.31 . This means that there is no need to maintain TOMOYO's own list for detecting memory leak. Removing the own list reduced use of exclusive sections. (11) Hooks for calling TOMOYO's functionalities were rewritten. ccs-patch-2.\*.diff were rewritten so that TOMOYO's hooks resemble LSM hooks. Some of TOMOYO's hooks are located next to LSM hooks. TOMOYO had hooks for kill(), tkill() and tgkill(). But hooks for sigqueue() and tgsigqueue() were missing. Hooks for sigqueue() and tgsigqueue() are added in TOMOYO 1.7.0 . open(pathname, O_RDONLY) opens "pathname" for reading, open(pathname, O_WRONLY) opens "pathname" for writing, open(pathname, O_RDWR) opens "pathname" for both reading and writing. However, it turned out that open(pathname, 3) opens "pathname" for doing ioctl only (i.e. no reading or writing). TOMOYO checks file's permission upon open() time, and does not check file's permission upon individual read()/write() requests. Until now, TOMOYO was checking "allow_read/write" permission when open(pathname, 3) was requested. But that behavior is not what I want because read() and write() are impossible. Regarding ioctl() requests, TOMOYO checks "allow_ioctl" permission upon individual ioctl() requests. Thus, I modified TOMOYO not to check "allow_read/write" permission for open(pathname, 3). (12) Moved TOMOYO's location under security/ directory. The TOMOYO's files were moved from fs/ directory to security/ccsecurity/ . The location in kernel config menu moved from "File systems" section to "Security options" section. The kernel config symbol CONFIG_SAKURA CONFIG_TOMOYO CONFIG_SYAORAN were merged into CONFIG_CCSECURITY . All kernel versions supported in TOMOYO 1.6.8 are supported in TOMOYO 1.7.0 . Vanilla kernels: * 2.4.30 - 2.4.37.5 * 2.6.11.12 - 2.6.31-rc8 Distribution kernels: * Fedora 9 (2.6.27.25-78.2.56.fc9) * Fedora 10 (2.6.27.30-170.2.82.fc10) * Fedora 11 (2.6.29.6-217.2.16.fc11) * CentOS 3.9 (2.4.21-60.EL) * CentOS 4.8 (2.6.9-89.0.9.EL) * CentOS 5.3 (2.6.18-128.7.1.el5) * Debian Etch (2.6.18-24etch4) * Debian Lenny (2.6.26-17lenny2) * Ubuntu 6.06 (2.6.15-54.79) * Ubuntu 8.04 (2.6.24-24.59) * Ubuntu 8.10 (2.6.27-14.39) * Ubuntu 9.04 (2.6.28-15.49) * Ubuntu 9.10 (2.6.31-9.29) * OpenSUSE 10.3 (2.6.22.19-0.4) * OpenSUSE 11.0 (2.6.25.20-0.5) * OpenSUSE 11.1 (2.6.27.29-0.1.1) * Vine Linux 4.2 (2.6.16-76.51vl4) * Asianux 2.0 (2.6.9-78.14AXS2) * Asianux 3.0 (2.6.18-53.25AXS3) * Gentoo * Hardened Gentoo * and mode... (I can create on demand) TOMOYO 1.7.0 has 17020 lines. 9812 lines are added and 11344 lines are deleted since TOMOYO 1.6.8 . As you can see from this statistic, a lot of modifications were made, and several bugs might remain. Also, I need to update documentation ( http://tomoyo.sourceforge.jp/1.7/ ) and adjust userland tools. Thus, at the moment, I don't provide installation using binary packages from repositories. I do hope that TOMOYO Linux can coexist with different security modules. The "void *security;" field is provided for various structures for LSM based security modules, but TOMOYO is far from utilizing the "void *security;" field. If TOMOYO is permitted to append two variables @@ -1480,6 +1482,10 @@ struct task_struct { /* bitmask of trace recursion */ unsigned long trace_recursion; #endif /* CONFIG_TRACING */ +#ifdef CONFIG_CCSECURITY + struct ccs_domain_info *ccs_domain_info; + u32 ccs_flags; +#endif }; /* Future-safe accessor for struct task_struct's cpus_allowed. */ into the "struct task_struct", TOMOYO can yield the "void *security;" field to those LSM modules which can utilize more efficiently (e.g. SELinux and Smack). TOMOYO 1.x is not using LSM. This means that, you can use TOMOYO 1.x with SELinux / Smack / AppArmor etc. at the same time and benefit from LSM's object oriented access restriction capability and TOMOYO's intention oriented behavior restriction capability. Lastly, I show an example configuration of profile. PROFILE_VERSION=20090903 PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes symlink.target=yes } PREFERENCE::permissive={ verbose=yes } PREFERENCE::enforcing={ verbose=yes penalty=0 } 0-COMMENT=-----Disabled Mode----- 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 1-COMMENT=-----Learning Mode----- 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } 2-COMMENT=-----Permissive Mode----- 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } 3-COMMENT=-----Enforcing Mode----- 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } CONFIG lines are used for configuring access control levels. Categories are shown below. file network capability ipc misc Configuration with category name overrides default configuration. For example, 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 0-CONFIG::file={ mode=learning grant_log=yes reject_log=yes } means that access controls for "file" category is configured as "learning mode" and access controls for other categories (i.e. "network", "capability", "ipc", "misc") are configured as "disabled mode". The "file" category has items shown below. execute open create unlink mkdir rmdir mkfifo mksock truncate symlink rewrite mkblock mkchar link rename chmod chown chgrp ioctl chroot mount umount pivot_root Configuration with item name overrides configuration without item name. For example, 1-CONFIG::file={ mode=learning grant_log=yes reject_log=yes } 1-CONFIG::file::execute={ mode=enforcing grant_log=yes reject_log=yes } means that program execution (and domain transition) is configured as "enforcing mode" and other items in "file" category (i.e. open, create, unlink, mkdir, rmdir, mkfifo, mksock, truncate, symlink, rewrite, mkblock, mkchar, link, rename, chmod, chown, chgrp, ioctl, chroot, mount, umount, pivot_root) are configured as "learning mode". Until now, it was impossible to separately configure access control mode for "program execution (and domain transition)" and other file related operations (e.g. creating files and opening files for reading/writing) because it was controlled by MAC_FOR_FILE entry. But in TOMOYO 1.7.0 , it became possible to separately configure. This change made it possible to firstly determine "what programs can execute what programs and how domain transitions are done" (by assigning "enforcing mode" to "CONFIG::file::execute" line) and secondly determine "what behaviors are permitted for individual domains" (by changing "CONFIG::file" line). This change also added new usages of TOMOYO (using TOMOYO for only auditing execve() parameters using TOMOYO's "execute_handler" directive, using TOMOYO for only restricting execve() requests) in addition to existing usage of TOMOYO (e.g. using TOMOYO for deploying DMZ for SSH sessions, using TOMOYO for deploying honey pots). The "network" category has items shown below. inet_udp_bind inet_udp_connect inet_tcp_bind inet_tcp_listen inet_tcp_connect inet_tcp_accept inet_raw_bind inet_raw_connect For example, 3-CONFIG::network={ mode=enforcing grant_log=yes reject_log=yes } 3-CONFIG::network::inet_tcp_accept={ mode=enforcing grant_log=no reject_log=no } means that TOMOYO generates access logs regarding networking operations other than TCP's accept() operations. The "capability" category has items shown below. inet_tcp_create inet_tcp_listen inet_tcp_connect use_inet_udp use_inet_ip use_route use_packet SYS_MOUNT SYS_UMOUNT SYS_REBOOT SYS_CHROOT SYS_KILL SYS_VHANGUP SYS_TIME SYS_NICE SYS_SETHOSTNAME use_kernel_module create_fifo create_block_dev create_char_dev create_unix_socket SYS_LINK SYS_SYMLINK SYS_RENAME SYS_UNLINK SYS_CHMOD SYS_CHOWN SYS_IOCTL SYS_KEXEC_LOAD SYS_PIVOT_ROOT SYS_PTRACE conceal_mount The "ipc" category has items shown below. signal The "misc" category has items shown below. env Today is Tomoyo Daidouji's birthday. Please enjoy the TOMOYO's world. :-)