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.u...@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. :-)
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
