Hello. TOMOYO Linux 1.6.7 was released. This release includes usability enhancement of policy management tools and functionality enhancement. Also, TOMOYO Linux 2.2.0 was merged into 2.6.29-git1 on March 27th, 2009. You can download from http://www.kernel.org/ . Below is the list of changes regarding ccs-patch package. (1) ENHANCEMENT: New condition "execute_handler" was added to "if" clause. I received a request from a customer that "I want to record all data sent to printers". It would be doable by inserting an execute_handler program which acts as "tee" program. But the customer wanted to use black-listing configurations so that the customer does not need to design TOMOYO's domain transition tree beforehand. This means that the customer will run programs in a single domain (by suppressing domain transition using "keep_domain" keyword). Therefore, I had to allow both execute_handler programs and other programs (e.g. "cat" and "grep") to access files for recording data sent to printers. This is not good. Therefore, I added new conditions "if task.type=execute_handler" and "if task.type!=execute_handler" so that only execute_handler programs (or other programs) can access required resources. (2) ENHANCEMENT: Condition "if task.type=execute_handler" is automatically added in learning mode. Learning mode does not append "if" clause. But learning without distinction between execute_handler programs and other programs will generate policy which allows both execute_handler programs and other programs to access. This will ruin the advantage of (1). Therefore, I modified to add "if task.type=execute_handler" automatically in learning mode if an entry was accessed by execute_handler programs. (3) ENHANCEMENT: File types and permissions support was added to "if" clause. In case I receive a request that "I want to forbid execution of setuid/setgid programs" in future, I modified to support conditions like "if path1.type=file" and "if path1.mode=0644" so that we can do access control which takes file types and DAC's permissions into account. Specifications are listed in the tail of this mail. (4) ENHANCEMENT: Memory quota for holding access logs was introduced. Until version 1.6.6, the amount of memory used for access logs were ceiled by MAX_GRANT_LOG and MAX_REJECT_LOG parameters in "number of items". But it will be convenient for users if we can ceil memory usage in "bytes". Therefore, I modified to support quota for holding access logs via /proc/ccs/meminfo . For example, # echo Dynamic: 1048576 > /proc/ccs/meminfo will ceil memory used for holding access logs by 1MB. (5) ENHANCEMENT: New config option was added to enable/disable auditing functionality. Hiroshi Shinji introduced TOMOYO into an embedded system which has only 4MB of RAM. There is no space for holding access logs within kernel memory for systems with only 4MB of RAM. This means that /proc/ccs/grant_log and /proc/ccs/reject_log will not be used. Therefore, I added a kernel config option CONFIG_TOMOYO_AUDIT to enable/disable /proc/ccs/grant_log and /proc/ccs/reject_log . (6) CHANGE: Only entries configured are shown in /proc/ccs/profile . Until version 1.6.6 , all "Functionality=Mode" pairs are always shown. But it might be annoying for users that MAC_FOR_CAPABILITY entries are shown even if the users configured only MAC_FOR_FILE entry. Therefore, I modified to show only entries configured are shown in /proc/ccs/profile . (7) ENHANCEMENT: Access control for ioctl() was added. I received a request from a customer that "I want to forbid operations which changes IP address of a network interfaces". I was considering restricting execution of programs like /sbin/ifconfig to meet that request. But I found that restricting ioctl() is better for that request. Therefore, I added MAC_FOR_IOCTL which restricts command number passed to ioctl() requests. The syntax is shown below. allow_ioctl pathname command_number (8) CHANGE: Pathname for sockets was changed. Until version 1.6.6 , a socket's pathname is represented as socket:[\$] . Since it is impossible to open a socket using open() or truncate a socket using truncate(), we did not see socket:[\$] in /proc/ccs/domain_policy . But it is possible to apply ioctl() on a socket. To be able to perform restriction of ioctl() more strictly by distinguishing socket's type, I changed a socket's pathname to socket:[family=\$:type=\$:protocol=\$] format. (9) ENHANCEMENT: New config option was added to specify built-in domain initializer programs. On PCs and servers, there is a program named /sbin/init , and TOMOYO loads policy when /sbin/init is requested. But some embedded systems do not have /sbin/init . On systems without /sbin/init , all programs will run in the <kernel> domain. This will ruin the advantage of TOMOYO's domain dividing ability. Therefore, I added a kernel config option CONFIG_TOMOYO_BUILTIN_INITIALIZERS to specify programs that will cause initialization of domain transition (i.e. "initialize_domain" keyword) on kernel compilation time. (10) NOTICE: ccs-patch-\*.diff until TOMOYO 1.6.6 is no longer applicable for TOMOYO 1.6.7 . 18 months has elapsed since I released TOMOYO 1.5.0 on September 20th, 2007. You can upgrade from TOMOYO 1.5.x to TOMOYO 1.6.x by just upgrading kernel and tool packages. Also, TOMOYO 2.2.0 which was merged into 2.6.29-git1 is based on TOMOYO 1.6.0 . Therefore, I terminate providing TOMOYO 1.5.x's binary packages and updates for ccs-patch-\*.diff . To implement (7), I had to modify ccs-patch-\*.diff . This means that ccs-patch-\*.diff until TOMOYO 1.6.6 is no longer applicable for TOMOYO 1.6.7 and vice versa. If you have problems in modifying ccs-patch-\*.diff for TOMOYO 1.6.7 , feel free to ask me. (11) BUGFIX: Fix profile read error. Incorrect profiles were shown in /proc/ccs/profile if either CONFIG_SAKURA or CONFIG_TOMOYO is disabled. (12) BUGFIX: Fix misplaced ccs_capable() call. (only 2.6.8-\* and 2.6.9-\*) Location to insert ccs_capable(TOMOYO_SYS_IOCTL) in sys_ioctl() was wrong since TOMOYO 1.1 . This bug existed only in ccs-patch-2.6.8-\*.diff and ccs-patch-2.6.9-\*.diff . Below is the list of changes regarding ccs-tools package. (1) ENHANCEMENT: ccs-editpolicy can edit more policy types. Until 1.6.6 , ccs-editpolicy can edit only system_policy and exception_policy and domain_policy . In 1.6.7 , ccs-editpolicy can edit profile and manager and meminfo as well. You can jump to one of system_policy / exception_policy / domain_policy / profile / manager / meminfo using 'w' key + 's' / 'e' / 'd' / 'p' / 'm' / 'u' key, while Tab key rounds system_policy / exception_policy / domain_policy only. To specify initial screen of ccs-editpolicy , you can use 'p' for profile / 'm' for manager, 'u' for meminfo as well as 's' for system_policy / 'e' for exception_policy / 'd' for domain_policy . (2) ENHANCEMENT: ccs-editpolicy supports browse only mode. If you give "readonly" option to ccs-editpolicy , policy editor will behave as policy browser. Also, if you give "refresh=interval" option, policy editor (or policy browser) will automatically reload policy in interval seconds. (3) ENHANCEMENT: ccs-init loads meminfo . New policy files /etc/ccs/meminfo.base and /etc/ccs/meminfo.conf were added. Until 1.6.6 , we were setting memory quota using /etc/ccs/ccs-post-init #! /bin/sh echo Private: 10485760 > /proc/ccs/meminfo echo Shared: 10485760 > /proc/ccs/meminfo In 1.6.7 , you can do the equivalent thing using /etc/ccs/meminfo.conf Private: 10485760 Shared: 10485760 Dynamic: 10485760 (4) ENHANCEMENT: ccs-loadpolicy can load more policy types. You can write to /proc/ccs/meminfo by executing "ccs-loadpolicy q". You can do like # echo Dynamic: 10485760 | ccs-loadpolicy -q (5) ENHANCEMENT: An agent program for editing embedded systems remotely was added. Normally, you can edit policies using ccs-editpolicy using logging into a system via ssh or telnet. But it is difficult to run ccs-editpolicy in a system with only 4MB of RAM. Therefore, I added an agent program "ccs-editpolicy-agent" which is executed in embedded environments (or emulator environments) so that you can edit policies from PC environments (or host environments) using ccs-editpolicy and ccs-loadpolicy and ccs-savepolicy . There is a merit that you don't need to prepare ncurses library for embedded systems. (Well, honestly speaking, I was not able to cross compile ncurses library for embedded systems.) (6) ENHANCEMENT: ccs-editpolicy can edit file policies in arbitrary directory. Until 1.6.6 , ccs-editpolicy_offline was able to edit policy files only in /etc/ccs/ or /etc/tomoyo/ directory. This is inconvenient for users when one wants to browse policy files made in other environments, for one has to copy policy files to /etc/ccs/ or /etc/tomoyo/directory. Therefore, I modified ccs-editpolicy to accept arbitrary directory. The program name ccs-editpolicy_offline was removed. In TOMOYO 1.6.7 , "ccs-editpolicy /etc/ccs/" edits policy files saved in /etc/ccs/ , "ccs-editpolicy /etc/tomoyo/" edits policy files saved in /etc/tomoyo/ , "ccs-editpolicy /home/kumaneko/192.168.1.1/" edits policy files saved in /home/kumaneko/192.168.1.1/ , "ccs-editpolicy 192.168.1.2:10000" edits /proc/ccs/ or /sys/kernel/security/tomoyo/ on 192.168.1.2 (via agent program liste****@192*****:10000 ). List of new conditions in "if" clause for TOMOYO 1.6.7 . Type of process. task.type=execute_handler Process is running as an execute_handler program. task.type!=execute_handler Process is running as a regular program. Type of file. path1.type=file path1 is a regular file. path1.type=directory path1 is a directory. path1.type=fifo path1 is a FIFO. path1.type=socket path1 is a socket. path1.type=symlink path1 is a symbolic link. path1.type=block path1 is a block device file. path1.type=char path1 is a character device file. path1.type!=file path1 is not a regular file. path1.type!=directory path1 is not a directory. path1.type!=fifo path1 is not a FIFO. path1.type!=socket path1 is not a socket. path1.type!=symlink path1 is not a symbolic link. path1.type!=block path1 is not a block device file. path1.type!=char path1 is not a character device file. Since path1.parent and path2.parent are always directory, TOMOYO does not support path1.parent and path2.parent for type of file. Device numbers of a device file where the file resides. path1.major=num1-num2 Device major number of a device file which path1 reside is between num1 and num2. path1.minor=num1-num2 Device minor number of a device file which path1 reside is between num1 and num2. path1.major!=num1-num2 Device major number of a device file which path1 reside is not between num1 and num2. path1.minor!=num1-num2 Device minor number of a device file which path1 reside is not between num1 and num2. Since a device file where path1.parent and path2.parent reside is always same as the device file where path1 resides (because cross device operation is not permitted), TOMOYO does not support path1.parent and path2.parent for device numbers. Device numbers of the device file itself. path1.dev_major=num1-num2 Device file's major number is between num1 and num2. path1.dev_minor=num1-num2 Device file's minor number is between num1 and num2. path1.dev_major!=num1-num2 Device file's major number is not between num1 and num2. path1.dev_minor!=num1-num2 Device file's minor number is not between num1 and num2. These conditions are valid only for path1.type=block or path1.type=char cases. DAC's permissions path1.perm=num1-num2 path1's permission is between num1 and num2. path1.perm!=num1-num2 path1's permission is not between num1 and num2. path1.perm=setuid path1's setuid bit is on. path1.perm!=setuid path1's setuid bit is off. path1.perm=setgid path1's setgid bit is on. path1.perm!=setgid path1's setgid bit is off. path1.perm=sticky path1's sticky bit is on. path1.perm!=sticky path1's sticky bit is off. path1.perm=owner_read path1's owner read bit is on. path1.perm!=owner_read path1's owner read bit is off. path1.perm=owner_write path1's owner write bit is on. path1.perm!=owner_write path1's owner write bit is off. path1.perm=owner_execute path1's owner execute bit is on. path1.perm!=owner_execute path1's owner execute bit is off. path1.perm=group_read path1's group read bit is on. path1.perm!=group_read path1's group read bit is off. path1.perm=group_write path1's group write bit is on. path1.perm!=group_write path1's group write bit is off. path1.perm=group_execute path1's group execute bit is on. path1.perm!=group_execute path1's group execute bit is off. path1.perm=others_read path1's others read bit is on. path1.perm!=others_read path1's others read bit is off. path1.perm=others_write path1's others write bit is on. path1.perm!=others_write path1's others write bit is off. path1.perm=others_execute path1's others execute bit is on. path1.perm!=others_execute path1's others execute bit is off. These conditions are applicable for path1.parent and path2.parent as well as path1 . If num1 and num2 is the same value, you can omit -num2 part. To specify value in octal format, start from 0 (e.g. path1.perm=0644 ). For example, allow_read/write /dev/null if path1.type=char path1.major=1 path1.minor=3 path1.perm=0666 will allow opening /dev/null for reading and writing only if /dev/null's type is character device file and /dev/null's major number is 1 and /dev/null's minor number is 3 and /dev/null's permission is 0666. Thank you for using TOMOYO Linux. ccs-patch-1.6.7-20090401.tar.gz MD5: ccc30ec17223625cdfc44df87ec1f623 ccs-tools-1.6.7-20090401.tar.gz MD5: dda77d0ea6a7fedd3f494f4338a8a952
TOMOYO
Fork