Info: Version 1.8.x is available.

Japanese Page

Last modified: $Date: 2024-03-30 11:25:00 +0000 (Sat, 30 Mar 2024) $

Policy Specifications of TOMOYO Linux

Index

1. Keywords Index

2. Introduction

2.1 Word Expression Rules

2.2 Wildcard Expression Rules

2.3 Memory Usage Information

3. Policy Files

3.1 Policy File's Location

3.2 Policy File's Modification

4. Domain Rules

4.1 Domain Definition

4.2 Domain Transition

4.3 Access Logs

5. Syntax Details

6. Advanced Features

6.1 Allowing policy modification by non root user.

6.2 Using conditional ACL.

6.3 Using stateful ACL.

6.4 Sleep penalty for policy violation.

6.5 Judging execute request outside the kernel.

6.6 Invoking alternative program for execute requests that are not permitted by policy.

1. Keywords Index

Used by /proc/ccs/profile and /etc/ccs/profile.conf

• CONFIG::file::execute
• CONFIG::file::transit
• CONFIG::file::open
• CONFIG::file::create
• CONFIG::file::unlink
• CONFIG::file::mkdir
• CONFIG::file::rmdir
• CONFIG::file::mkfifo
• CONFIG::file::mksock
• CONFIG::file::truncate
• CONFIG::file::symlink
• CONFIG::file::rewrite
• CONFIG::file::mkblock
• CONFIG::file::mkchar
• CONFIG::file::link
• CONFIG::file::rename
• CONFIG::file::chmod
• CONFIG::file::chown
• CONFIG::file::chgrp
• CONFIG::file::ioctl
• CONFIG::file::chroot
• CONFIG::file::mount
• CONFIG::file::umount
• CONFIG::file::pivot_root
• CONFIG::misc::env
• CONFIG::capability::inet_tcp_create
• CONFIG::capability::inet_tcp_listen
• CONFIG::capability::inet_tcp_connect
• CONFIG::capability::use_inet_udp
• CONFIG::capability::use_inet_ip
• CONFIG::capability::use_route
• CONFIG::capability::use_packet
• CONFIG::capability::use_kernel_module
• CONFIG::capability::create_fifo
• CONFIG::capability::create_block_dev
• CONFIG::capability::create_char_dev
• CONFIG::capability::create_unix_socket
• CONFIG::capability::SYS_MOUNT
• CONFIG::capability::SYS_UMOUNT
• CONFIG::capability::SYS_REBOOT
• CONFIG::capability::SYS_CHROOT
• CONFIG::capability::SYS_KILL
• CONFIG::capability::SYS_VHANGUP
• CONFIG::capability::SYS_TIME
• CONFIG::capability::SYS_NICE
• CONFIG::capability::SYS_SETHOSTNAME
• CONFIG::capability::SYS_LINK
• CONFIG::capability::SYS_SYMLINK
• CONFIG::capability::SYS_RENAME
• CONFIG::capability::SYS_UNLINK
• CONFIG::capability::SYS_CHMOD
• CONFIG::capability::SYS_CHOWN
• CONFIG::capability::SYS_IOCTL
• CONFIG::capability::SYS_KEXEC_LOAD
• CONFIG::capability::SYS_PIVOT_ROOT
• CONFIG::capability::SYS_PTRACE
• CONFIG::capability::conceal_mount
• CONFIG::network::inet_udp_bind
• CONFIG::network::inet_udp_connect
• CONFIG::network::inet_tcp_bind
• CONFIG::network::inet_tcp_listen
• CONFIG::network::inet_tcp_connect
• CONFIG::network::inet_tcp_accept
• CONFIG::network::inet_raw_bind
• CONFIG::network::inet_raw_connect
• CONFIG::ipc::signal
• PREFERENCE::audit
• PREFERENCE::learning
• PREFERENCE::permissive
• PREFERENCE::enforcing

Used by /proc/ccs/exception_policy and /etc/ccs/exception_policy.conf

• aggregator
• initialize_domain
• no_initialize_domain
• keep_domain
• no_keep_domain
• file_pattern
• path_group
• number_group
• address_group
• allow_read
• allow_env
• deny_rewrite
• deny_autobind

Used by /proc/ccs/domain_policy and /etc/ccs/domain_policy.conf

• allow_execute
• allow_transit
• allow_read
• allow_write
• allow_read/write
• allow_create
• allow_unlink
• allow_mkdir
• allow_rmdir
• allow_mkfifo
• allow_mksock
• allow_mkblock
• allow_mkchar
• allow_truncate
• allow_symlink
• allow_link
• allow_rename
• allow_rewrite
• allow_chmod
• allow_chown
• allow_chgrp
• allow_ioctl
• allow_mount
• allow_unmount
• allow_chroot
• allow_pivot_root
• allow_env
• allow_network
• allow_capability
• allow_signal
• use_profile
• ignore_global_allow_read
• ignore_global_allow_env
• execute_handler
• denied_execute_handler
• quota_exceeded
• transition_failed

Used by /proc/ccs/manager and /etc/ccs/manager.conf

• manage_by_non_root

2. Introduction

2.1 Word Expression Rules

TOMOYO Linux performs pathname based access control. A pathname may contain not only alphabet and number but also space and carriage return and multibyte (e.g. kanji) characters. Thus, to be able to handle any characters correctly, TOMOYO Linux follows the rules shown below to represent a word. A word means all tokens that are treated as string data, such as pathnames, comments, environment variable's names, parameters for program execution.

• NUL character (0x00) is used for indicating end of string. Thus you cannot include \000 in a word.
• \ character (0x5C) is used for indicating octal expression. Thus, you need to use \\ to represent a \.
• Characters 0x01 - 0x20 and 0x7F - 0xFF are represented using octal expression \ooo .
• The rest characters (i.e. 0x21 - 0x5B and 0x5D - 0x7E) are represented as is.

• Space character (0x20) is used as a delimiter that separates words. Line feed character (0x0A) is used as a delimiter that separates lines.
• Only words that follow the rule above and the delimiters (i.e. space character and line feed characters) are valid. All other characters are regarded as space character. Multiple spaces are automatically compressed into one space. Leading and trailing spaces are automatically deleted.

Some examples are shown below.

Pathname must start with / character. Pathnames that end with / character are interpreted as directories, and that don't end with / character are interpreted as non-directories.

Exceptions are pipes and sockets. Pipes begin with "pipe:" and sockets begin with "socket:" when these pathnames are accessed via /proc/PID/fd/ directory.

2.2 Wildcard Expression Rules

Like temporary files, pathnames may contain randomly selected characters. Thus, you often need to define pathnames using wildcards. TOMOYO Linux supports wildcards shown below.

2.3 Memory Usage Information

The memory used by TOMOYO Linux can be obtained via /proc/ccs/meminfo . The unit is byte.

• Policy:        Memory used for holding access permissions.
• Audit logs:   Memory used for holding access logs.
• Query lists:  Memory used for handling policy violation in enforcing mode.

TOMOYO Linux supports memory quota for limiting maximum memory used by TOMOYO Linux.

You can set memory quota by writing to /etc/ccs/meminfo.conf .

3. Policy Files

3.1 Policy File's Location

Policy files are files that contain access permissions. These files are automatically loaded into the kernel upon boot.

When a system boots, /sbin/init is executed. When the execution of /sbin/init is requested and if /sbin/ccs-init exists, /sbin/ccs-init is executed, and /sbin/init is executed after /sbin/ccs-init terminates.

/sbin/ccs-init loads policy files in /etc/ccs/ directory via the kernel's /proc/ccs/ interface.

There are more interfaces for obtaining information. These interfaces don't have corresponding policy files.

3.2 Policy File's Modification

Register the name of programs or domains that can modify policy via the kernel's /proc/ccs/ interface. Only

• Processes with programs listed in /proc/ccs/manager
• Processes with domainnames listed in /proc/ccs/manager

can modify policy via the kernel's /proc/ccs/ interface. Some examples are show below.

By default, only processes with UID = 0 and EUID = 0 can modify policy via this interface. But by doing configurations described in Allowing policy modification by non root user., non root user can modify policy via this interface.

Exception is, processes that belong to domains with profiles for learning mode can append access permissions to /proc/ccs/domain_policy by simply requesting the access.

4. Domain Rules

4.1 Domain Definition

TOMOYO Linux gives access permissions as per a domain. It is managed via /proc/ccs/domain_policy.

In TOMOYO Linux, every process belongs to a single domain, and all programs belong to different domain. Even the two processes are executing the same program, if their previous domains differ, they belong to different domain.

All domains are defined originating from "<kernel>" domain, which the kernel process belongs to. Since /sbin/init is invoked by the "<kernel>" domain, the domain for /sbin/init is defined as "<kernel> /sbin/init". Since /etc/rc.d/rc is invoked by /sbin/init invoked by the kernel, the domain for /etc/rc.d/rc is defined as "<kernel> /sbin/init /etc/rc.d/rc".

4.2 Domain Transition

When a process tries to execute a program, the steps shown below are performed.

There is an exception. If either

• The execute request was denied at "Checking permission" or "Deciding destination domain" but the domain the process that issued execute request belongs to has denied_execute_handler keyword.
• The domain the process that issued execute request belongs to has execute_handler keyword.

and

• The process that issued execute request is not a process executed by execute_handler or denied_execute_handler keyword.

the steps shown below are performed instead for the steps shown above. The usage of this exception is explained in "Judging execute request outside the kernel." and "Invoking alternative program for execute requests that are not permitted by policy."

4.3 Access Logs

TOMOYO Linux generates two types of access logs. One contains access requests that didn't violate domain policy. The other contains access requests that violated domain policy. The former is called grant log and is readable via /proc/ccs/grant_log . The latter is called reject log and is readable via /proc/ccs/reject_log . A utility program /usr/sbin/ccs-auditd is included for reading these logs and saving the logs as files.

Some examples are shown below. The first log is generated by execute request.

This log shows that a process that belongs to "<kernel> /usr/sbin/sshd /bin/bash" domain attempted to execute /bin/cat , and the arguments were "cat" and "/etc/fstab", environment variables were "HOSTNAME=tomoyo" "TERM=vt100" "SHELL=/bin/bash" "HISTSIZE=1000" "SSH_CLIENT=192.168.1.2\0402845\04022" "SSH_TTY=/dev/pts/0" "USER=root" "LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:" "MAIL=/var/spool/mail/root" "PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/sbin:/root/bin" "PWD=/root" "LANG=C" "SHLVL=1" "HOME=/root" "LOGNAME=root" "CVS_RSH=ssh" "SSH_CONNECTION=192.168.1.2\0402845\040192.168.1.7\04022" "LESSOPEN=|/usr/bin/lesspipe.sh\040%s" "G_BROKEN_FILENAMES=1" "_=/bin/cat". Also, process information such as PID, UID are shown.

The next log is generated by opening a file for reading.

This log shows that a process that belongs to "<kernel> /usr/sbin/sshd /bin/bash /bin/cat" domain opened /etc/fstab for reading.

The next log is generated when a new domain is created.

This log shows that a domain named "<kernel> /usr/sbin/sshd /bin/bash /bin/bash /bin/audit-exec-param /bin/cat" was created and profile 1 was assigned. TOMOYO Linux automatically creates domains as needed. When a domain is automatically created, the profile number of the domain the process that requested program execution belongs to is inherited.

The next log is generated when a program that is different from the program being requested was executed because of Judging execute request outside the kernel.

This log shows that a process that belongs to a domain named "<kernel> /usr/sbin/sshd /bin/bash /bin/bash" attempted to execute a program, but since the execute_handler keyword is specified to the domain, /bin/audit-exec-param was executed, and arguments passed to /bin/audit-exec-param were "/bin/audit-exec-param" "<kernel>\040/usr/sbin/sshd\040/bin/bash\040/bin/bash" "/bin/bash" "pid=3007\040uid=0\040gid=0\040euid=0\040egid=0\040suid=0\040sgid=0\040fsuid=0\040fsgid=0\040state[0]=0\040state[1]=0\040state[2]=0" "/bin/cat" "2" "20" "cat" "/etc/fstab" "HOSTNAME=tomoyo" "SHELL=/bin/bash" "TERM=vt100" "HISTSIZE=1000" "SSH_CLIENT=192.168.1.2\0402845\04022" "SSH_TTY=/dev/pts/0" "USER=root" "LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:" "PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/sbin:/root/bin:/usr/sbin" "MAIL=/var/spool/mail/root" "PWD=/root" "LANG=C" "HOME=/root" "SHLVL=2" "LOGNAME=root" "CVS_RSH=ssh" "SSH_CONNECTION=192.168.1.2\0402845\040192.168.1.7\04022" "LESSOPEN=|/usr/bin/lesspipe.sh\040%s" "G_BROKEN_FILENAMES=1" "_=/bin/cat". To avoid /bin/audit-exec-param affected by environment variables such as LD_PRELOAD, environment variables are moved to arguments.

In this way, an access log consists of 3 lines (or 4 lines since /usr/sbin/ccs-auditd inserts an empty line), and they are in the domain policy format and appendable to the domain policy. Pick up portions you want to permit from reject log and save (for example, /var/log/tomoyo/diff.txt) and you can add to domain policy by doing

Therefore, you don't need to use "learning mode" from the beginning. If you wish, you can use "permissive mode" from the beginning and let reject logs generated, then edit reject logs and append to domain policy when developing domain policy. When domain policy is generated by "learning mode", process state (the first line of an access logs) is not taken into account. But when domain policy is generated from reject logs, you can use Using conditional ACL. from the beginning. For example, generate a reject log by not using "learning mode" and append like

then, you can give more precise permission compared to the permission appended by "learning mode"'s log (shown below).

5. Syntax Details

/proc/ccs/profile

TOMOYO Linux can perform several MACs besides MAC for files, but to reduce the load of policy managements, you can disable MACs you think unnecessary.

List up functions and their modes in "$number-$variable=$value" format. The $number is profile number between 0 and 255. To modify profile, use "ccs-setlevel" or "ccs-loadpolicy" commands.

Each domain is assigned one profile. To assign profile to domains, use "ccs-setprofile" or "ccs-editpolicy" or "ccs-loadpolicy" commands.

You can see profiles currently assigned to domains using "ccs-editpolicy" command.
You can see profiles currently assigned to processes using "ccs-pstree" command.
If you saved current policy using "ccs-savepolicy" command, the currently assigned profile number is saved as use_profile line of domain policy.

To read or modify current profiles, operate like below.

(Example)
cat /proc/ccs/profile
ccs-savepolicy -p
ccs-setlevel 1-CONFIG::file::execute=learning
echo 1-CONFIG::file::execute=learning | ccs-loadpolicy -p

See also: Policy File's Modification

You can specify one of modes shown below for functionalities that start with "CONFIG".

CONFIG::file::execute

Specifies access control level regarding program execution and domain transition.

CONFIG::file::transit

Specifies access control level regarding domain transition without program execution. (Valid only in 1.7.2 and later.)

CONFIG::file::open

Specifies access control level regarding file open for reading and/or writing.

CONFIG::file::create

Specifies access control level regarding file create.

CONFIG::file::unlink

Specifies access control level regarding file delete.

CONFIG::file::mkdir

Specifies access control level regarding directory create.

CONFIG::file::rmdir

Specifies access control level regarding directory delete.

CONFIG::file::mkfifo

Specifies access control level regarding fifo create.

CONFIG::file::mksock

Specifies access control level regarding UNIX domain socket create.

CONFIG::file::truncate

Specifies access control level regarding file truncate.

CONFIG::file::symlink

Specifies access control level regarding symlink create.

CONFIG::file::rewrite

Specifies access control level regarding file overwrite.

CONFIG::file::mkblock

Specifies access control level regarding block device file create.

CONFIG::file::mkchar

Specifies access control level regarding character device file create.

CONFIG::file::link

Specifies access control level regarding link create.

CONFIG::file::rename

Specifies access control level regarding rename.

CONFIG::file::chmod

Specifies access control level regarding chmod.

CONFIG::file::chown

Specifies access control level regarding chown.

CONFIG::file::chgrp

Specifies access control level regarding chgrp.

CONFIG::file::ioctl

Specifies access control level regarding ioctl.

CONFIG::file::chroot

Specifies access control level regarding chroot.

CONFIG::file::mount

Specifies access control level regarding mount.

CONFIG::file::umount

Specifies access control level regarding umount.

CONFIG::file::pivot_root

Specifies access control level regarding pivot_root.

CONFIG::misc::env

Specifies access control level regarding environment variable names (a.k.a. envp[]).

CONFIG::capability::inet_tcp_create

Specifies access control level regarding creation of TCP sockets.

CONFIG::capability::inet_tcp_listen

Specifies access control level regarding TCP socket's listen operation.

CONFIG::capability::inet_tcp_connect

Specifies access control level regarding TCP socket's connect operation.

CONFIG::capability::use_inet_udp

Specifies access control level regarding use of UDP sockets.

CONFIG::capability::use_inet_ip

Specifies access control level regarding use of RAW sockets.

CONFIG::capability::use_route

Specifies access control level regarding use of ROUTE sockets.

CONFIG::capability::use_packet

Specifies access control level regarding use of PACKET sockets.

CONFIG::capability::use_kernel_module

Specifies access control level regarding use of create_module(2) init_module(2) delete_module(2) syscall.

CONFIG::capability::create_fifo

Specifies access control level regarding creation of FIFO using mknod(2) syscall.

CONFIG::capability::create_block_dev

Specifies access control level regarding creation of block device file using mknod(2) syscall.

CONFIG::capability::create_char_dev

Specifies access control level regarding creation of character device file using mknod(2) syscall.

CONFIG::capability::create_unix_socket

Specifies access control level regarding creation of UNIX domain socket using mknod(2) syscall.

CONFIG::capability::SYS_MOUNT

Specifies access control level regarding use of mount(2) syscall.

CONFIG::capability::SYS_UMOUNT

Specifies access control level regarding use of umount(2) syscall.

CONFIG::capability::SYS_REBOOT

Specifies access control level regarding use of reboot(2) syscall.

CONFIG::capability::SYS_CHROOT

Specifies access control level regarding use of chroot(2) syscall.

CONFIG::capability::SYS_KILL

Specifies access control level regarding use of kill(2) tkill(2) tgkill(2) syscall with non 0 signal.

CONFIG::capability::SYS_VHANGUP

Specifies access control level regarding use of vhangup(2) syscall.

CONFIG::capability::SYS_TIME

Specifies access control level regarding use of stime(2) settimeofday(2) adjtimex(2) syscall.

CONFIG::capability::SYS_NICE

Specifies access control level regarding use of nice(2) setpriority(2) syscall.

CONFIG::capability::SYS_SETHOSTNAME

Specifies access control level regarding use of sethostname(2) setdomainname(2) syscall.

CONFIG::capability::SYS_LINK

Specifies access control level regarding use of link(2) syscall.

CONFIG::capability::SYS_SYMLINK

Specifies access control level regarding use of symlink(2) syscall.

CONFIG::capability::SYS_RENAME

Specifies access control level regarding use of rename(2) syscall.

CONFIG::capability::SYS_UNLINK

Specifies access control level regarding use of unlink(2) syscall.

CONFIG::capability::SYS_CHMOD

Specifies access control level regarding use of chmod(2) fchmod(2) syscall.

CONFIG::capability::SYS_CHOWN

Specifies access control level regarding use of chown(2) fchown(2) lchown(2) syscall.

CONFIG::capability::SYS_IOCTL

Specifies access control level regarding use of ioctl(2) compat_sys_ioctl(2) syscall.

CONFIG::capability::SYS_KEXEC_LOAD

Specifies access control level regarding use of kexec_load(2) syscall.

CONFIG::capability::SYS_PIVOT_ROOT

Specifies access control level regarding use of pivot_root(2) syscall.

CONFIG::capability::SYS_PTRACE

Specifies access control level regarding use of ptrace(2) syscall.

CONFIG::capability::conceal_mount

Specifies access control level regarding mount requests that shadow existent mounts.

CONFIG::network::inet_udp_bind

Specifies access control level regarding UDP socket's local address restriction.

CONFIG::network::inet_udp_connect

Specifies access control level regarding UDP socket's remote address restriction.

CONFIG::network::inet_tcp_bind

Specifies access control level regarding TCP socket's bind() operation.

CONFIG::network::inet_tcp_listen

Specifies access control level regarding TCP socket's listen() operation.

CONFIG::network::inet_tcp_connect

Specifies access control level regarding TCP socket's connect() operation.

CONFIG::network::inet_tcp_accept

Specifies access control level regarding TCP socket's accept() operation.

CONFIG::network::inet_raw_bind

Specifies access control level regarding RAW socket's local address restriction.

CONFIG::network::inet_raw_connect

Specifies access control level regarding RAW socket's remote address restriction.

CONFIG::ipc::signal

Specifies access control level regarding signal transmission requests.

PREFERENCE::audit

Specifies preference on auditing.

"max_grant_log=" limits the max number of grant logs that the kernel can hold.

"max_reject_log=" limits the max number of reject logs that the kernel can hold.

PREFERENCE::learning

Specifies preference on learning mode.

"verbose=" controls whether to print policy violation messages or not.

"max_entry=" controls the max number of ACL entries that are automatically appended.

"exec.realpath=" controls whether the dereferenced pathname of the requested program should be learned when adding an "allow_execute" entry.

"exec.argv0=" controls whether the invocation name should be learned when adding an "allow_execute" entry.

"symlink.target=" controls whether the content of the symbolic link should be learned when adding an "allow_symlink" entry.

PREFERENCE::permissive

Specifies preference on permissive mode.

"verbose=" controls whether to print policy violation messages or not.

PREFERENCE::enforcing

Specifies preference on enforcing mode.

"verbose=" controls whether to print policy violation messages or not.

"penalty=" controls how long (in units of 0.1 second) should the process that violated policy sleep for.

/proc/ccs/domain_policy

This file contains definition of all domains and permissions that are granted to each domain.

Lines from the next line to a domain definition ( any lines starting with "<kernel>") to the previous line to the next domain definitions are interpreted as access permissions for that domain.

You can specify additional conditions as needed. The syntax for specifying additional conditions are described in Using conditional ACL. Also, how to switch process's state as needed and use the process's state for conditions is described in Using stateful ACL.

To read or modify current domain policy, operate like below.

(Example) Selecting specific domain and appending ACLs. The domain will be created if nonexistent.
printf "<kernel> /sbin/init\nallow_read /etc/passwd\n" | ccs-loadpolicy -d

(Example) Selecting specific domain and appending ACLs. The domain won't be created if nonexistent.
printf "select <kernel> /sbin/init\nallow_read /etc/passwd\n" | ccs-loadpolicy -d

(Example) Selecting specific domain and removing ACLs.
printf "select <kernel> /sbin/init\ndelete allow_read /etc/passwd\ndelete allow_read /etc/shadow\n" | ccs-loadpolicy -d

(Example) Deleting specific domain.
printf "delete <kernel> /sbin/init\n" | ccs-loadpolicy -d

(Example) Reading current domain policy.
cat /proc/ccs/domain_policy

See also: Policy File's Modification

allow_execute

This keyword grants execution of the specified pathname. No wildcards are permitted for the pathname. If you have to use wildcards, use aggregator keyword before granting execute permission using this keyword.

(Example) allow_execute /bin/ls

See also: Domain Transition aggregator

allow_transit

This keyword grants domain transition to the specified pathname without executing program. No wildcards are permitted for the pathname. (Valid only in 1.7.2 and later.)

(Example) allow_transit //app=cgi1\040id=10000

allow_write

This keyword grants the specified pathname to be opened for writing.

(Example) allow_write /dev/null

See also: path_group

allow_read

This keyword grants the specified pathname to be opened for reading.

(Example) allow_read /proc/meminfo

See also: path_group

allow_read/write

This keyword grants the specified pathname to be opened for reading and writing.

(Example) allow_read/write /dev/null

See also: path_group

allow_create

This keyword grants the specified pathname to be created.

(Example) allow_create /var/lock/subsys/crond 0644

See also: path_group

allow_unlink

This keyword grants the specified pathname to be deleted.

(Example) allow_unlink /var/lock/subsys/crond

See also: path_group

allow_mkdir

This keyword grants the specified pathname to be created. The pathname must be a directory.

(Example) allow_mkdir /tmp/logwatch.\*/ 0755

See also: path_group

allow_rmdir

This keyword grants the specified pathname to be deleted. The pathname must be a directory.

(Example) allow_rmdir /tmp/logwatch.\*/

See also: path_group

allow_mkfifo

This keyword grants creation of FIFO by the specified pathname.

(Example) allow_mkfifo /dev/initctl 0600

See also: path_group

allow_mksock

This keyword grants creation of UNIX domain socket by the specified pathname.

(Example) allow_mksock /dev/log 0700

See also: path_group

allow_mkblock

This keyword grants creation of block device file by the specified pathname.

(Example) allow_mkblock /dev/hdc 0640 22 0

See also: path_group

allow_mkchar

This keyword grants creation of character device file by the specified pathname.

(Example) allow_mkchar /dev/null 0644 1 3

See also: path_group

allow_truncate

This keyword grants the specified pathname to be truncated or extended.

(Example) allow_truncate /etc/mtab

See also: path_group

allow_symlink

This keyword grants creation of symbolic link by the specified pathname.

(Example) allow_symlink /dev/cdrom

See also: path_group

allow_link

This keyword grants creation of hard link by the specified pathnames.

(Example) allow_link /etc/mtab~\$ /etc/mtab~

See also: path_group

allow_rename

This keyword grants renaming of the specified pathnames.

(Example) allow_rename /etc/mtab.tmp /etc/mtab

See also: path_group

allow_rewrite

This keyword grants the specified pathname to be rewritten when the pathname is specified by deny_rewrite keyword.

(Example) allow_rewrite /var/log/messages

See also: path_group deny_rewrite

allow_chmod

This keyword grants changing DAC's permissions.

(Example) allow_chmod /dev/mem 0644

See also: path_group number_group

allow_chown

This keyword grants changing DAC's owner.

(Example) allow_chown /dev/sda 0

See also: path_group number_group

allow_chmod

This keyword grants changing DAC's group.

(Example) allow_chgrp /dev/audio 92

See also: path_group number_group

allow_ioctl

This keyword grants doing IOCTL request with the specified command numbers and the specified pathnames.

Regarding the meaning of IOCTL request's command numbers, please refer manuals provided by each module with IOCTL functionality. For example, IOCTL request with command number 21585 means, on i386 platform, FIOCLEX command which turns on the file's close-on-exec flag. For example, IOCTL request with command number 35088 means SIOCGIFNAME command which retrieves the name of network interface.

See also: Using conditional ACL.

allow_mount

To grant mount permission, use allow_mount keyword followed by "$devicefile $mountpoint $filesystem $options". The $devicefile need to be a canonicalized file if the $filesystem requires device file. The $mountpoint must be a canonicalized file. The $options is a hexadecimal integer expression.

To grant "mount -o remount $mountpoint" permission, use allow_mount keyword followed by "any $mountpoint --remount $options".

To grant "mount --bind $source_dir $dest_dir", use "allow_mount $source_dir $dest_dir --bind $options".
To grant "mount --move $source_dir $dest_dir" permission, use "allow_mount $source_dir $dest_dir --move $options".
The $source_dir and $dest_dir must be canonicalized directory.

Kernel 2.6.15 and later supports "Shared Subtree" functionality.
To grant "mount --make-unbindable $mountpoint" permission, use allow_mount keyword followed by "any $mountpoint --make-unbindable $options".
To grant "mount --make-private $mountpoint" permission, use allow_mount keyword followed by "any $mountpoint --make-private $options".
To grant "mount --make-slave $mountpoint" permission, use allow_mount keyword followed by "any $mountpoint --make-slave $options".
To grant "mount --make-shared $mountpoint" permission, use allow_mount keyword followed by "any $mountpoint --make-shared $options".

(Example)
allow_mount none /dev/pts/ devpts 0x0
allow_mount /proc /proc/ proc 0x0
allow_mount usbdevfs /proc/bus/usb/ usbdevfs 0x0
allow_mount none /data/ tmpfs 0xE
allow_mount none /dev/shm/ tmpfs 0xE
allow_mount /dev/hdc /var/www/ ext2 0xF
allow_mount any / --remount 0x0

allow_unmount

To grant unmount request, use allow_unmount keyword followed by a canonicalized directory.

(Example)
allow_unmount /mnt/cdrom/

allow_chroot

To grant chroot permission, use allow_chroot keyword followed by a canonicalized directory.
Usually, grant /var/empty/sshd/ that sshd uses. In addition, if you have applications that runs in the chroot'ed environment or applications that uses chroot (for example, /usr/share/empty/ is used by vsftpd), grant such directories too.

(Example)
allow_chroot /var/empty/sshd/
allow_chroot /usr/share/empty/
allow_chroot /var/www/html/
allow_chroot /

allow_pivot_root

To grant pivot_root permission, use allow_pivot_root keyword followed by the new root's canonicalized directory and the previous root's canonicalized directory.
Usually, you don't need this keyword.

allow_env

To restrict the name of environment variables, use allow_env keyword followed by "the name of environment variable".

The execve() system call, which is used to execute a program, accepts filename and argv[] and envp[]. Many programs behave differently depending on envp[].

The purpose of this keyword is to restrict the environment variables passed to an executed programs.

See also: allow_env

allow_capability

To grant capability permission, use allow_capability keyword followed by a capability. The following capabilities are applicable.

The purpose of allow_capability keyword is to restrict system calls that a program can call. You can restrict more strictly with other keyword and policy files for some system calls.

• You can restrict creation of block device files using allow_mkblock keyword.
• You can restrict creation of character device files using allow_mkchar keyword.
• You can restrict creation of FIFOs using allow_mkfifo keyword.
• You can restrict creation of UNIX domain sockets using allow_mksock keyword.
• You can restrict creation of symbolic links using allow_symlink keyword.
• You can restrict deletion of non-directories using allow_unlink keyword.
• You can restrict combination of pathnames that can be hard linked using allow_link keyword.
• You can restrict combination of pathnames that can be renamed using allow_rename keyword.
• You can restrict combination of IOCTL's command numbers and pathnames using allow_ioctl keyword.
• You can restrict IP addresses and ports using allow_network keyword.
• You can restrict signal numbers and target domain using allow_signal keyword.
• You can restrict devices and directories for mount operations using allow_mount keyword.
• You can restrict directories that can unmount using allow_unmount keyword.
• You can restrict directories that can chroot to using allow_chroot keyword.
• You can restrict directories that can exchange using allow_pivot_root keyword.

allow_network

To grant permission for socket operations, use allow_network keyword followed by protocol(TCP or UDP or RAW) and IP address and port number (for TCP or UDP) / protocol number (for RAW). This permission is applicable to IPv4 and IPv6.

Use of "::" for IPv6 address representation is not supported. You need to use "0:0:0:0:0:0:0:1" for "::1".

To reduce the labor of repeating same IP addresses, you can define groups like pathnames.

See also: address_group

allow_signal

To grant permissions for signals, use allow_signal keyword followed by signal number and target domain.
There are two exceptions. If signal number is 0, it is always granted. If the target domain and the source domain are the same, it is always granted.

In other cases, signals are granted only when the signal number matches and the target domain starts with the target domain declared with this keyword.

If only <kernel> is declared as a target domain, the source domain can send signals to any domain with that signal number.

use_profile

This keyword indicates the profile number currently assigned to this domain. The profile number is an integer between 0 and 255.

ignore_global_allow_read

This keyword ignores pathnames specified by allow_read keyword in exception policy. You can use this keyword for domains you want to ignore globally readable files.

See also: allow_read

ignore_global_allow_env

This keyword ignores environment variables names specified by allow_env keyword in exception policy. You can use this keyword for domains you want to ignore globally acceptable environment variable names.

See also: allow_env

execute_handler

This domain executes only one program specified by this keyword. You can use this keyword for domains you want to validate parameters before executing the requested program.

If this keyword is specified, only one program specified by this keyword regardless of the mode specified by CONFIG::file::execute. Thus, if the pathname specified by this program cannot be executed, no programs can be executed from this domain.

See also: denied_execute_handler CONFIG::file::execute allow_execute

denied_execute_handler

This domain executes this program only when execute request was rejected and the mode of CONFIG::file::execute is enforcing. If this keyword is not specified and the mode of CONFIG::file::execute is enforcing, execute request is rejected.

Exception is, if the execute_handler keyword is specified, denied_execute_handler keyword is ignored.

quota_exceeded

This keyword indicates that this domain has failed to append entry in learning mode since the number of entries reached to the limit specified by PREFERENCE::learning keyword. You need to reduce the number of entries for this domain by tuning policy.

See also: PREFERENCE::learning

transition_failed

This keyword indicates that some process in this domain was not able to transit to new domain when processing the execute request.

If this domain was assigned a profile with CONFIG::file::execute=enforcing , the execute request was rejected.

Otherwise, the execute request was not rejected. In that case, the process continued execution without domain transition. Since the reason of transition failure is either "the name of the domain was too long" or "the kernel was unable to allocate memory", you need to consider "suppressing domain transitions" or "increasing memory quota" if you are planning to assign a profile with CONFIG::file::execute=enforcing to this domain.

See also: keep_domain Memory Usage Information

/proc/ccs/exception_policy

To read or modify current exception policy, operate like below.

(Example)
echo 'file_pattern /proc/\$/status' | ccs-loadpolicy -e
echo 'delete file_pattern /proc/\$/status' | ccs-loadpolicy -e
cat /proc/ccs/exception_policy

See also: Policy File's Modification

file_pattern

To declare pathname pattern, use file_pattern keyword followed by pathname pattern. The pathname pattern must be a canonicalized Pathname. This keyword is not applicable to neither granting execute permissions nor domain definitions.
For example, canonicalized pathname that contains a process ID (i.e. /proc/PID/ files) needs to be grouped in order to make access control work well.

path_group

To declare pathname group, use path_group keyword followed by name of the group and pathname pattern.
For example, if you want to group all files under home directory, you can define

in the exception policy and use like

to grant file access permission.

number_group

To declare number group, use number_group keyword followed by name of the group and number ranges.
For example, if you want to group 0644 and 0664, you can define

in the exception policy and use like

to grant access permission.

address_group

To declare address group, use address_group keyword followed by name of the group and IP address pattern.
For example, if you want to group all local addresses, you can define

in the exception policy and use like

to grant network access permission.

allow_read

To grant unconditionally readable permissions, use allow_read keyword followed by canonicalized file. This keyword is intended to reduce size of domain policy by granting read access to library files such as GLIBC and locale files. Exception is, if ignore_global_allow_read keyword is given to a domain, entries specified by this keyword are ignored.

See also: allow_read ignore_global_allow_read

allow_env

To grant unconditionally acceptable environment variables' names, use allow_env keyword followed by the name of environment variables. This keyword is intended to reduce memory usage for commonly granted environment variables (e.g. PATH and HOME). You should not grant dangerous environment variables like LD_PRELOAD . Exception is, if ignore_global_allow_env keyword is given to a domain, entries specified by this keyword are ignored.

See also: ignore_global_allow_env allow_env

deny_rewrite

To deny overwriting already written contents of file (such as log files) by default, use deny_rewrite keyword followed by pathname pattern. Files whose pathname match the patterns are not permitted to open for writing without append mode or truncate unless the pathnames are explicitly granted using allow_rewrite keyword in domain policy.

See also: allow_rewrite

aggregator

To deal multiple programs as a single program, use aggregator keyword followed by name of original program and aggregated program. This keyword is intended to aggregate similar programs.

For example, /usr/bin/tac and /bin/cat are similar. By specifying "aggregator /usr/bin/tac /bin/cat", you can run /usr/bin/tac in the domain for /bin/cat .

For example, /usr/sbin/logrotate for Fedora Core 3 generates programs like /tmp/logrotate.\?\?\?\?\?\? and run them, but TOMOYO Linux doesn't allow using patterns for granting execute permission and defining domains. By specifying "aggregator /tmp/logrotate.\?\?\?\?\?\? /tmp/logrotate.tmp", you can run /tmp/logrotate.\?\?\?\?\?\? as if /tmp/logrotate.tmp is running.

See also: allow_execute

initialize_domain

To initialize domain transition when specific program is executed, use initialize_domain directive.

• initialize_domain "program" from "domain"
• initialize_domain "program" from "the last program part of domain"
• initialize_domain "program"

If the part "from" and after is not given, the entry is applied to all domain. If the "domain" doesn't start with "<kernel>", the entry is applied to all domain whose domainname ends with "the last program part of domain".

This directive is intended to aggregate domain transitions for daemon program and program that are invoked by the kernel on demand, by transiting to different domain.

See also: Domain Transition no_initialize_domain

no_initialize_domain

To deny the effect of "initialize_domain" directive, use "no_initialize_domain" directive.

• no_initialize_domain "program" from "domain"
• no_initialize_domain "program" from "the last program part of domain"
• no_initialize_domain "program"

Use this directive when you don't want to initialize domain transition.

See also: Domain Transition initialize_domain

keep_domain

To prevent domain transition when program is executed from specific domain, use keep_domain directive.

• keep_domain "program" from "domain"
• keep_domain "program" from "the last program part of domain"
• keep_domain "domain"
• keep_domain "the last program part of domain"

If the part "from" and before is not given, this entry is applied to all program. If the "domain" doesn't start with "<kernel>", the entry is applied to all domain whose domainname ends with "the last program part of domain".

This directive is intended to reduce total number of domains and memory usage by suppressing unneeded domain transitions.

See also: Domain Transition no_keep_domain

no_keep_domain

To deny the effect of "keep_domain" directive, use "no_keep_domain" directive.

• no_keep_domain "program" from "domain"
• no_keep_domain "program" from "the last program part of domain"
• no_keep_domain "domain"
• no_keep_domain "the last program part of domain"

Use this directive when you want to escape from a domain that is kept by "keep_domain" directive.

See also: Domain Transition keep_domain

deny_autobind

To prevent specific local port from being selected automatically, use deny_autobind keyword followed by local port number.
This keyword is intended to prevent specific local port from being bound for temporary use. For example, some proxy server uses local port 8080, so port 8080 should not be bound by other programs for temporary use.

(Example)
deny_autobind 1-1023
deny_autobind 8080

/proc/ccs/query

This file is used to manually grant or reject individual access requests when the policy violation occurs in enforcing mode. If a policy violation occur in a process whose domain is assigned a profile for enforcing mode, the administrator can judge interactively using "ccs-queryd" command.

/proc/ccs/manager

This file is used to read or append the list of programs or domains that can write to /proc/ccs/ interface.

manage_by_non_root

By default, only processes with both UID = 0 and EUID = 0 can modify policy via /proc/ccs/ interface. You can use this keyword to allow policy modification by non root user.

/proc/ccs/.domain_status

This is a view (of a DBMS) that contains only profile number and domainnames of domain so that "ccs-setprofile" command can do line-oriented processing easily.

/proc/ccs/meminfo

This file is to show the total RAM used to keep policy in the kernel by TOMOYO Linux.

(Example)
cat /proc/ccs/meminfo

/proc/ccs/grant_log

This file holds the granted log. The reader process returns immediately if no granted logs exists. To wait until a granted log is generated, use select(2) for readability. The max number of logs that the kernel can hold is limited to max_grant_log parameter of PREFERENCE::audit, so read out timely.

(Example)
cat /proc/ccs/grant_log

/proc/ccs/reject_log

This file holds the rejected log. The reader process returns immediately if no violation logs exists. To wait until a violation log is generated, use select(2) for readability. The max number of logs that the kernel can hold is limited to max_reject_log parameter of PREFERENCE::audit, so read out timely.

(Example)
cat /proc/ccs/reject_log

/proc/ccs/self_domain

This file is to show the name of domain the caller process belongs to.

(Example)
cat /proc/ccs/self_domain

/proc/ccs/.process_status

This file is used by "ccs-pstree" command to show "list of processes currently running" and "domains which each process belongs to" and "profile number which the domain is currently assigned" like "pstree" command. This file is writable by programs that aren't registered as policy manager.

/proc/ccs/version

This file is used for getting TOMOYO Linux's version.

(Example)
cat /proc/ccs/version

6. Advanced Features

6.1 Allowing policy modification by non root user.

By default, only processes with both UID = 0 and EUID = 0 can modify policy via /proc/ccs/ interface. But if you want to permit policy modification via /proc/ccs/ interface by non root user, you can write this keyword like

to disable UID and EUID checks. Also, you can write this keyword like

to enable UID and EUID checks again. Use chown/chmod as needed since the owner of /proc/ccs/ interface is root.
To be able to do this steps, /sbin/ccs-init also executes /etc/ccs/ccs-post-init if /etc/ccs/ccs-post-init is executable. Therefore, to allow access to /proc/ccs/ interface by user demo, create /etc/ccs/ccs-post-init with

and initialize like

Then, user demo will be able to access policy directories and policy editors.

6.2 Using conditional ACL.

You can add conditions (e.g. UID and GID) as needed. The condition clause are appended to the tail of each permission using "if" directive.

The following variables are available.

"path1" corresponds to the first pathname of operations that requires pathnames, and "path2" corresponds to the second pathname of operations that requires pathnames. For example, the case of "allow_rename file1 file2", path1 corresponds to file1 and path2 corresponds to file2.

"path1" except "path1.parent" is not available for pathnames that don't exist. Thus, you can't use when creating pathnames (such as allow_create keyword).

"path1.parent" is always available.

"path2.parent" is available only for operations that require 2 pathnames (i.e. allow_link and allow_rename keywords).

"path2" is available only for mount operations.

"path1" is not supported when accessing via "sysctl" (i.e. accessing files under /proc/sys/ directories using "sysctl" instead for "open").

The following variables and conditions are available for allow_execute keyword.

The following conditions are also available.

Type of process

Type of file.

Since path1.parent and path2.parent are always directory, TOMOYO Linux does not support path1.parent and path2.parent for type of file.

Device numbers of a device file where the file resides.

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 Linux does not support path1.parent and path2.parent for device numbers.

If num1 and num2 is the same value, you can omit -num2 part.

Device numbers of the device file itself.

These conditions are valid only for path1.type=block or path1.type=char cases.

If num1 and num2 is the same value, you can omit -num2 part.

DAC's permissions

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

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.

The following conditions for allow_symlink keyword are also available.

6.3 Using stateful ACL.

Since TOMOYO Linux doesn't require modification of userland applications, it is impossible to change the range of accessible resources without domain transition. But there are cases you wish to change the range of accessible resources without domain transition. For example, you might wish to change the range of accessible resources depending on the client's IP address. To support such cases, you can assign state variables to each processes and you can use the state variables in Using conditional ACL.

Each task.state can take an integer value between 0 and 255. To change state variable, append " ; set " part after an ACL.

When using the state variables, please be careful with the following points.

• The domain a process belongs to is automatically updated upon execution of a program, but the state variables of the process are not updated unless they are explicitly specified using " ; set " part. Thus, be careful with forgetting to reset when needed.
• The state variables are updated when the access request is permitted by the policy. Thus, situations that the access request was not processed although the state variables were updated can happen because of errors after checking the policy (e.g. out of memory).
• If an IP address is included in both @TRUSTED_HOSTS and @UNTRUSTED_HOSTS, the permission which matched first is used. So, be careful with using order dependent policy.

6.4 Sleep penalty for policy violation.

You can make the process which violated policy in enforcing mode sleep for specified period.

This feature is a safeguard to avoid that the CPU usage remains 100% when policy violation occurs in an infinite loop. Usually, making processes sleep for 0.1 second is enough.

This feature is not applied against network's receive operation so that attackers cannot make services sleep for long time (in other words, delay your system's response) by intentionally sending TCP connection requests and UDP packets from unwanted sources.

6.5 Judging execute request outside the kernel.

Basically, TOMOYO Linux controls whether to execute a program or not according to the domain policy. You can check parameters using exec.argv and exec.envp described in Using conditional ACL. But this approach support only simple pattern matching and you need to specify what programs are permitted to be executed beforehand.

Therefore, TOMOYO Linux supports a mechanism named execute_handler. If this mechanism is used, the kernel no longer controls whether to execute a requested program or not, and the kernel merely executes the program specified by execute_handler, and the program specified by execute_handler determines whether to execute the requested program or not, and the program specified by execute_handler executes the requested program only if the program specified by execute_handler considers it is appropriate.

In Linux, the behavior "execute a program" means "overwrite the process which requested to execute a program with the requested program's image" and "the process which requested to execute a program cannot regain control if the execute request was succeeded". Therefore, the process which requested to execute a program can receive a notification only when the execute request was failed.
For example, let's consider a situation where a process running as program-A attempts to execute program-B.
When the process running as program-A requests the execution of program-B, the kernel checks the domain policy for "whether it is appropriate to execute program-B from a process running as program-A or not" and the kernel overwrites the process running as program-A with program-B if the kernel considers it is appropriate, and the kernel doesn't overwrite the process running as program-A with program-B and notifies the process running as program-A that execution of program-B is not permitted if the kernel considers it is not appropriate.

When execute_handler is specified, a different program program-C specified as execute_handler mediates this behavior.
When the process running as program-A requests the execution of program-B, the kernel overwrites the process running as program-A with program-C to let the program-C judge whether it is appropriate to execute program-B from a process running as program-A or not. The process now running as program-C determines whether it is appropriate to execute program-B from a process running as program-A or not, and the process now running as program-C requests the execution of program-B (and the kernel will overwrite the process now running as program-C with program-B) if the process now running as program-C considers it is appropriate, and the process now running as program-C terminates without executing program-B if the process now running as program-C considers it is not appropriate.

As stated above, this mechanism has a side effect that it becomes impossible to notify the process running as program-A that the requested program (i.e. program-B) was not executed since program-C abandons a mean to notify the process running as program-A that the execute request of program-B was not accepted.
But, even if execute_handler is not specified, there are various factors that cause "the execute request was accepted but the program terminated before starting the expected behavior" such as "the process was unable to read shared libraries", "the process received KILL signal", "the system became out of memory and the process was killed by OOM killer". In other words, there are uncertainties between "the execute request did not fail" and "the executed program starts the expected behavior".
Viewing in this light, there is no guarantee that "the program starts expected behavior unless the process receives a notification that the execution of the program failed" from the beginning. And, it is possible to say that it is an acceptable result that the program-C specified by execute_handler failed to notify the process previously running as program-A that the execution of program-B failed.

TOMOYO Linux's assumes that the administrator knows what programs needs to be executed from what programs beforehand and permits execution of minimal programs. Thus, assuming that unexpected execute request which are not permitted by policy won't occur as long as the system is running properly, it is OK to accept all execute requests. If an execute request that should not be accepted occurs, you can take different actions such as terminating the process instead of rejecting the request by using denied_execute_handler mechanism. So, you don't have to let the kernel judge whether to execute the program or not alone.

Thus, you can let external userland program judge whether to execute the requested program or not occurred from a domain by specifying execute_handler keyword to the domain.

If you try to judge inside the kernel, there are few library functions available and it is more likely to fail when allocating contiguous memory area. But if you try to judge outside the kernel, there are many library functions available and it is less likely to fail when allocating contiguous memory area, and you can do more detailed checking. So, you can let external userland program specified by execute_handler keyword examine parameters and let the program execute the requested program only if parameters are appropriate.

The side effect of this approach is that there is no mean to notify the process that the execute request was not accepted when it is not appropriate to execute the requested program. But since you can freely customize the program for execute_handler keyword, you can even judge using ssh to ask remotely.

To use this feature, specify like below.

The program specified by execute_handler keyword receives the following parameters. Compare with allow_execute log described in Access Logs.

• argv[0] contains the pathname of the program specified by execute_handler keyword.
• argv[1] contains the name of the domain which the process which issued an execute request belongs to.
• argv[2] contains the name of the program which the process which issued an execute request.
• argv[3] contains information of the process which the process which issued an execute request.
• argv[4] contains the name of the program which was requested by the process.
• argv[5] contains the number of arguments.
• argv[6] contains the number of environment variables.
• From argv[7] to argv[6 + argc] contains the arguments.
• From argv[7 + argc] to argv [6 + argc + envc] contains the environment variables.
• All environment variables are cleared for safety.
• Other resources such as standard input/output are inherited.

Be careful with the following notes when you use this feature.

• You need not to and should not give execute permission (allow_execute keyword) to the program specified by execute_handler keyword.
• This mechanism can't work if a process cannot access the program specified by execute_handler keyword because the process is running inside a chroot environment. Since it is dangerous to allow execution of programs outside the chroot environment, the program specified by execute_handler keyword is searched from the current process's / directory rather than the current process's namespace's / directory.
• This mechanism can't work if the domain for the program specified for execute_handler keyword doesn't exist. So, you need to prepare domains by (for example) creating a domain for the program specified by execute_handler keyword just under the <kernel> and mark the program specified by execute_handler keyword using initialize_domain keyword.
• The program specified by execute_handler keyword is invoked with all environment variables cleared so that the program won't be affected by some dangerous environment variables (e.g. LD_PRELOAD). This means that even environment variable PATH is not set, so please be careful when executing external programs. Also, I recommend you to assign profile for enforcing mode against the domain for the program specified by execute_handler keyword.

A source code named audit-exec-param.c is included as a sample program of how to use this mechanism in the ccs-tools source package. You can customize freely.

This mechanism is just providing a hook. How to utilize this hook is up to you.

6.6 Invoking alternative program for execute requests that are not permitted by policy.

TOMOYO Linux's approach is "know what programs needs to be executed from what programs beforehand and create policy that permits execution of minimal programs". Thus, you can not only reject unnecessary execution requests but also do different behavior.

By default, if an execute request of a program which is not permitted by allow_execute keyword occurs in enforcing mode, the kernel rejects the execute request. But assuming that you know what programs needs to be executed from what programs beforehand, an execute request of a program which is not permitted by allow_execute keyword will not occur as long as the process is keeping control, and you can regard that the process is not keeping control (in other words, the process already lost control) if such request occurs.

Attackers steal control of a process by attacking security holes such as buffer overflow and attempt to execute commands such as shells. If the process does not need to execute the shell (in other words, you needn't to give permission like "allow_execute /bin/bash"), it is considered that the process has already lost control at the moment of the execution request of shells.

Normally, when execution of a program which is not permitted by the policy is requested, the kernel merely reject the request. But it is unlikely that the process gets back control (in other words, the process resumes proper operations) by just rejecting the request if the request is issued by the process that has lost control.
In Linux, "execute a program" means that the current process is overwritten by the requested program and transfer control to the requested program. This means that a process gets back control by overwriting the process with different program even if the process has lost control because of buffer overflow.

The control of a process which has once lost control by the attacker and is overwritten by a program requested by the attacker depends on the program used for overwriting. If a program like shells is executed, the control remains on the attacker's side (in other words, the owner of the process) because shells accept whatever the user requested. But if a program which terminates silently (e.g. /bin/true) is executed, the control will not remains on the attacker's side because the process owned by the attacker will terminate immediately.

As described above, an event that "an execute request of an unnecessary program is issued by an attacker" depending on how you look at it. You can consider that "the attacker is giving the system a chance to get back control on the system's side".
Thus, TOMOYO Linux provides a mechanism that executes different program instead of merely rejecting the request when an execute request of a program which is not permitted by policy occurs. How to utilize this mechanism is up to you.

For example, you can replace the execute request of a program which is not permitted by the policy with /bin/true so that the process which requested the execution of a program which is not permitted by the policy will terminate immediately.

For example, you can replace the execute request of shells with a honey pot client's program and observe what requests the attacker issues.

For example, you can forcibly terminate the login session.

For example, you can show warning message like "You are not permitted to execute this program." which is similar to Ubuntu's command-not-found package (which tells the user in what package the requested command is included).

For example, you can change a firewall's configuration if you succeeded to derive the IP address of the attacker.

To use this feature, specify like below.

Notes on this feature is the same as Judging execute request outside the kernel.

Return to index page.