Info: Version 1.3 is available.

# TOMOYO Linux Install manual

Last modified: $Date: 2011-11-20 09:56:56 +0900 (Sun, 20 Nov 2011) $

# Index

- Preparation
- Install Kernel
- Install Tool
- Boot Test
- Defining Range for Protection
- Designing Login Operation
- Protecting Device Files (Optional)
- Preparing Policy
- About Default Policy
- Defining Policy Managers
- Modifying Shutdown Procedure
- Changes for Audit Logs
- Creating Profiles
- Creating Exception Policy
- Changes for logrotate
- Changes for prelink
- Changes for anacron
- Changes for cron
- Changes for Targeted Policy
- Creating Policy
- Accept Mode
- Operations for logrotate
- Operations for anacron
- Updating Exception Policy
- Accept Mode
- Tuning Policy
- Adding from Audit Logs
- Patterning File Access Permissions
- Patterning Network Access Permissions
- Add conditions to ACLs
- Permissive Mode
- Production State
- Enforce mode

# Preparation

There are no limitations for distributions. But since it is impossible to cover all distributions, this manual covers "RedHat Linux 9", "Fedora Core 3" and "Debian Sarge".

The size of policy files gets smaller by uninstalling unnecessary applications. You should know what application you want to run on the system.

## Install Kernel

To compile kernel, see TOMOYO Linux kernel compilation.

## Install Tool

To compile tools, run the following commands.

cd /root/ # Download source of tools for TOMOYO Linux. wget -O ccs-tools-1.2-20060903.tar.gz 'http://sourceforge.jp/frs/redir.php?m=jaist&f=/tomoyo/21579/ccs-tools-1.2-20060903.tar.gz' # Extract. tar -zxf ccs-tools-1.2-20060903.tar.gz # Compile. make -sC ccstools/

## Boot Test

Boot with TOMOYO Linux kernel, and check the system works properly.

After you confirmed the system works properly, save the content of /proc/ccs/status as /root/security/status.txt . This file contains the topics controllable for this kernel. This file is used as a hint when creating profiles (described later).

mkdir -p /root/security cat /proc/ccs/status > /root/security/status.txt

## Defining Range for Protection

You can apply "TOMOYO (Domain-Based Mandatory Access Control) support" to all programs that are executed between the invocation of /sbin/init and the power failure. But you can also apply to only specific programs such as http server and ssh server if you wish.

Hereafter, this manual refers "Strict Policy" as a policy that covers all programs and "Targeted Policy" as a policy that covers only specific programs.

Covering all programs is more secure, but covering only specific programs is more easier. At this step, decide the range covered by MAC.

Note that "SAKURA (Domain-Free Mandatory Access Control) support" and "SYAORAN (Tamper-Proof Device Filesystem) support" are applied to all programs.

## Designing Login Operation

You want to login to servers using ssh for maintenance or some other purposes. At this step, design what operations you want to allow for login operation.

### Reinforce the Login Authentication (Optional) The purpose of this step is to improve security for remote login using ssh. This step is optional, but performing this step is recommended, for it's very easy. TOMOYO Linux can't protect sshd from exploit codes like SELinux. (SELinux modifies sshd to protect from exploit codes.) Therefore, TOMOYO Linux allows crackers ssh login easier than SELinux if sshd or PAM has vulnerability. But, the threat is not only buffer overflows. There is a threat that a cracker logs in using proper username and passwords. Many users use password authentication or public-key authentication for ssh login. But, in fact, the passwords are cracked by brute force attacks, the system gets configured as a platform for phishing. Therefore, it is important that you prepare additional authentication mechanism on the basis that the sshd authentication are run through. Read the paper "Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security" for details. You can make programs for additional authentication mechanism as you like. Create the programs at this step, and confirm that the program works as you intended. By allowing login authentications for multiple times, the system can provide access restrictions based on the protection levels assigned to resources. In normal cases, users who have passed login authentication can access to both resources that needn't to be kept under strict control and resources that have to be kept under strict control. But by introducing authentication programs named /opt/bin/auth1 and /opt/bin/auth2 like the figure show below, you can grant access to resources that needn't to be kept under strict control for users who have passed only login authentication, and grant access to resources that have to be kept under strict control for users who have passed all authentication.
### Delegating a part of the administrator's task (Optional) You can delegate a part of administration tasks. For example, you can delegate updating WWW contents for HTTP service and restarting httpd process to other administrators. Everybody logs in as root, and run the programs described in "Reinforce the Login Authentication" for each delegated person, and only the delegated person can perform only the delegated tasks. Determine whom to delegate and what task to delegate at this step, design how to divide domains, create the programs that splits the domains. It is possible to use shells (such as /bin/bash and /bin/tcsh) as the programs that splits the domains, but everybody can enter into every domain, so it's not desirable. Therefore, create the programs with authentication mechanism and confirm that the program works as you intended. For example, users named "SAKURA" "TOMOYO" "SYAORAN" "CERBERUS" "YUE" are registered on the system and each user logs in using ssh. By dividing domains like the figure shown below, you can grant per-user access permissions. In the same manner, for example, roles named "manager" "webmaster" "auditor" "user" "anonymous" are needed and each role logs in using ssh. By dividing domains like the figure shown below, you can grant per-role access permissions.

## Protecting Device Files (Optional)

If you want to use "SYAORAN (Tamper-Proof Device Filesystem) support", configure at this step.

Do the following operation to create /.syaoran .

echo '#! /bin/sh' > /.syaoran echo 'mount -n -t syaoran -o accept=/root/security/syaoran.conf none /dev' >> /.syaoran echo 'exec /sbin/init "$@"' >> /.syaoran chmod 700 /.syaoran

To mount this filesystem automatically before /sbin/init starts, add "init=/.syaoran" to the TOMOYO Linux's kernel command line. I recommend you to add "init=/.syaoran" to the boot loader's configuration file because it is a bother specifying every time.

Do the following operation to create initial /root/security/syaoran.conf that contains all entries.

/root/ccstools/makesyaoranconf > /root/security/syaoran.conf

If you are using udev, do the following operation too.

echo DENY_CONCEAL_MOUNT=3 > /root/security/profile0.txt

Reboot with TOMOYO Linux kernel and run the system. Only device files that are actually opened are recorded. The result of file access tracing is readable via the file .syaoran which exists just under the mount point.

You need to be careful with the following two things.

You need to somehow explicitly open device files for swap partitions, for device files for swap partitions aren't opened when mounted. This means that device files for swap partitions will be excluded from .syaoran and you will be unable to mount swap partition. Run the following command to open device files for swap partitions explicitly. (The following assumes that swap partition is /dev/sda3 . Change the filename according to swap partition on your system.)

touch /dev/sda3

If you want to allow using pty for ssh logins, you need to login via ssh once. If you forget to login via ssh, the file /dev/ptmx won't be opened, and /dev/ptmx will be excluded from .syaoran . The absence of /dev/ptmx causes absence of pty for ssh logins.

ssh localhost

Run the following command to update /root/security/syaoran.conf . Only necessary entries (i.e. actually opened files) will be included.

cat /dev/.syaoran > /root/security/syaoran.conf

Reboot with TOMOYO Linux and make sure all necessary entries are included in /root/security/syaoran.conf . If the system doesn't work properly, possibly necessary entries were excluded, so retry from creating initial /root/security/syaoran.conf that contains all entries.

You can delete dead links and unused directories in /root/security/syaoran.conf . But please be careful not to delete mount points (usually "shm" and "pts").

# Preparing Policy

Please use normal kernel for operations in this chapter.
If you use TOMOYO Linux's kernel, /root/ccstools/savepolicy will be executed on shutdown and modifications you made on /root/security/exception_policy.txt will be lost.

## About Default Policy

TOMOYO Linux doesn't have default policy files distributed with softwares. Administrators need to create policy files using "accept mode".
The example policies are available to help your understanding. You may use these examples as a guide, but you MUST NOT use these examples as default policies.

## Defining Policy Managers

Create /root/security/manager.txt and list up programs that are allowed to update policies via /proc/ccs/ interface.
Specifically, "loadpolicy" that reloads policy, "editpolicy" that edits policy, "setlevel" that changes control level, "ld-watch" that updates globally readable files, "ccs-queryd" that grants access requests interactively.

cat > /root/security/manager.txt << EOF /root/ccstools/loadpolicy /root/ccstools/editpolicy /root/ccstools/setlevel /root/ccstools/ld-watch /root/ccstools/ccs-queryd EOF

## Modifying Shutdown Procedure

To save on-memory policies onto disk just before power off, modify the shutdown script to run /root/ccstools/savepolicy . Actual locations to modify depends on distributions. In many cases, since the final program invoked in the shutdown script under /etc/init.d/ directory is the program to power off, save on-memory policies just before the invocation of the program.

If you are using RedHat Linux 9 or Fedora Core 3, modify as follows.

/etc/rc.d/init.d/halt
Before | After
exec $command $HALTARGS | /root/ccstools/savepolicy exec $command $HALTARGS

If you are using Debian Sarge, modify as follows. To create and include domains for executing halt/reboot among the domain policy, run halt/reboot once before invoking savepolicy.

/etc/init.d/halt | /etc/init.d/reboot
Before | After | Before | After
halt -d -f -i $poweroff $hddown | halt --help 2> /dev/null /root/ccstools/savepolicy halt -d -f -i $poweroff $hddown | reboot -d -f -i | reboot --help 2> /dev/null /root/ccstools/savepolicy reboot -d -f -i

## Changes for Audit Logs

TOMOYO Linux can record "access granted logs" and "access rejected logs" for "TOMOYO (Domain-Based Mandatory Access Control) support". The logs are in the form of domain policy so that the logs can be directly appended to domain policy. Add the "access rejected logs" to domain policy if you consider you should allow the access.

You can use a daemon program that reads from /proc/ccs/info/grant_log and /proc/ccs/info/reject_log and writes to files. Run in the following way from (for example) /etc/rc.local .

/root/ccstools/ccs-auditd $location_to_store_access_granted_logs $location_to_store_access_rejected_logs

You may give /dev/null for $location_to_store_access_granted_logs if you don't want "access granted logs". But since ccs-auditd doesn't have filtering functions, be careful with the disk's free space if you want to save "access granted logs".

You may give /dev/null for $location_to_store_access_rejected_logs if you don't want "access rejected logs".

If you don't want neither "access granted logs" nor "access rejected logs", you needn't to run ccs-auditd , though I recommend you to save "access rejected logs". This manual assumes that "access rejected logs" is saved in /var/log/tomoyo/reject_log.txt .

/root/ccstools/ccs-auditd /dev/null /var/log/tomoyo/reject_log.txt

Create directories manually for storing access logs.

mkdir -p /var/log/tomoyo

If you want to rotate using "logrotate", create /etc/logrotate.d/tomoyo with the following content.

/var/log/tomoyo/reject_log.txt { weekly rotate 9 missingok notifempty nocreate }

## Creating Profiles

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.

You can switch the MACs and their initial control status by creating several profiles and specifying the profile index number at kernel command line. Specifically, the parameter CCS=$INDEX (where $INDEX is an integer) given in the kernel command line corresponds to the profile /root/security/profile$INDEX.txt to use.

Refer the descriptions below and create profiles for "accept mode", "permissive mode", "enforce mode". Only topics included in /root/security/status.txt are configurable. The topics included in /root/security/status.txt vary depending on the kernel configuration.

Name | Control | Accept mode supported
MAC_FOR_FILE | File Access | Yes
MAC_FOR_CAPABILITY::inet_tcp_create | Use of TCP socket | Yes
MAC_FOR_CAPABILITY::inet_tcp_listen | Listening TCP socket | Yes
MAC_FOR_CAPABILITY::inet_tcp_connect | Connecting TCP socket | Yes
MAC_FOR_CAPABILITY::use_inet_udp | Use of UDP socket | Yes
MAC_FOR_CAPABILITY::use_inet_ip | Use of RAW socket | Yes
MAC_FOR_CAPABILITY::use_route | Use of ROUTE socket | Yes
MAC_FOR_CAPABILITY::use_packet | Use of PACKET socket | Yes
MAC_FOR_CAPABILITY::use_kernel_module | Use of kernel modules | Yes
MAC_FOR_CAPABILITY::create_fifo | Creating FIFO | Yes
MAC_FOR_CAPABILITY::create_block_dev | Creating block device file | Yes
MAC_FOR_CAPABILITY::create_char_dev | Creating character device file | Yes
MAC_FOR_CAPABILITY::create_unix_socket | Creating UNIX domain socket | Yes
MAC_FOR_CAPABILITY::SYS_MOUNT | Mounting filesystem | Yes
MAC_FOR_CAPABILITY::SYS_UMOUNT | Unmounting filesystem | Yes
MAC_FOR_CAPABILITY::SYS_REBOOT | Rebooting the system | Yes
MAC_FOR_CAPABILITY::SYS_CHROOT | Changing the "/" directory | Yes
MAC_FOR_CAPABILITY::SYS_KILL | Sending signals | Yes
MAC_FOR_CAPABILITY::SYS_VHANGUP | Use of vhangup | Yes
MAC_FOR_CAPABILITY::SYS_TIME | Setting system's clock | Yes
MAC_FOR_CAPABILITY::SYS_NICE | Setting process priority | Yes
MAC_FOR_CAPABILITY::SYS_SETHOSTNAME | Setting hostname or domainname | Yes
MAC_FOR_CAPABILITY::SYS_LINK | Creating hard link | Yes
MAC_FOR_CAPABILITY::SYS_SYMLINK | Creating symbolic link | Yes
MAC_FOR_CAPABILITY::SYS_RENAME | Renaming file | Yes
MAC_FOR_CAPABILITY::SYS_UNLINK | Deleting file | Yes
MAC_FOR_CAPABILITY::SYS_CHMOD | Changing file's permissions | Yes
MAC_FOR_CAPABILITY::SYS_CHOWN | Changing file's owner or group | Yes
MAC_FOR_CAPABILITY::SYS_IOCTL | Use of ioctl | Yes
MAC_FOR_CAPABILITY::SYS_KEXEC_LOAD | Loading new kernel | Yes
MAC_FOR_NETWORK | IP addresses and port numbers | Yes
MAC_FOR_BINDPORT | Local port numbers | Yes
MAC_FOR_CONNECTPORT | Remote port numbers | Yes
MAC_FOR_SIGNAL | Combination of signal numbers and destination domains | Yes
DENY_CONCEAL_MOUNT | Forbid mount requests that hides an existing mount | No
RESTRICT_CHROOT | Enable restrictions for chroot directories | Yes
RESTRICT_MOUNT | Enable restrictions for mount parameters | Yes
RESTRICT_UNMOUNT | Forbid unmount requests for specified directories | No
DENY_PIVOT_ROOT | Forbid pivot_root requests | No
RESTRICT_AUTOBIND | Forbid assigning specific local port numbers for automatic local port assignment function | No
TRACE_READONLY | Dump Canonicalized Pathname that write requests failed due to read only filesystem | -
MAX_ACCEPT_FILES | Limits the max number of file ACL entries that are automatically appended during accept mode | -
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 | -
TOMOYO_VERBOSE | Dump domain policy violation messages to syslog | -
MAX_ENFORCE_GRACE | Wait before rejecting access request when the request violates policy in enforce mode | -

You can give the following values for TRACE_READONLY and RESTRICT_AUTOBIND

Value | Meaning
0 | Off. Works as if regular kernel.
1 | On.

You can give the following values for MAX_ACCEPT_FILES

Value | Meaning
any integer | The max number of file ACL entries that are automatically appended during accept mode. The default is given at the kernel compilation time.

You can give the following values for MAX_GRANT_LOG and MAX_REJECT_LOG

Value | Meaning
any integer | The max number of logs that the kernel can hold. The default is given at the kernel compilation time. You may give 0 if you don't need logs.

You can give the following values for TOMOYO_VERBOSE

Value | Meaning
0 | Don't dump domain policy violation messages.
1 | Dump domain policy violation messages.

You can give the following values for MAX_ENFORCE_GRACE

Value | Meaning
any integer | The max grace time in seconds. If the administrator tells the kernel not to reject the request that violated policy in enforce mode, the request will be granted.

You can give the following values for all but listed above.

Value | Meaning
0 | Disabled. Works as if regular kernel.
1 | Accept mode. Not rejected if the request violates policy. Automatically appended to policy.
2 | Permissive mode. Not rejected if the request violates policy. Not appended to policy automatically.
3 | Enforce mode. Rejected if the request violates policy.

## Creating Exception Policy

Register pathnames with patterns that likely exists on all Linux systems.
Register pathnames with patterns using the "file_pattern" directive in /root/security/exception_policy.txt .
When a file operation are performed and the requested pathname matches to a patterned pathname registered with "file_pattern" directive, policy is generated using patterned pathnames.
The following is the guideline.

- Files under /proc/PID/ directory.
- Files under /sys/ directory. (Applicable to 2.6 kernels only)
- Some files under /dev/ directory.
- Policy files under /root/security/ directory.
- Manual pages.
- Spool directories.
- Temporary files used for sending and receiving mails.
- Temporary files used by man command.
- Temporary files used by mount command.

TOMOYO Linux needs more patterned pathnames depending on the applications installed and their configurations. You can add missing patterned pathnames after running the system.

Register files that are allowed to be read by all programs.
Register pathnames using the "allow_read" directive in /root/security/exception_policy.txt . No patterns allowed.
When a read access is requested and the requested pathname matches to a pathname registered with "allow_read" directive, the read access is granted without checking domain policy.
The following is the guideline.

- Dynamically-linked library files that are registered with ldconfig.
- Some files under /proc/ directory.
- Some locale data under /usr/share/locale/ directory.

Register programs that initializes the domain transition history.
Register programs using the "initializer" directive in /root/security/exception_policy.txt . No patterns allowed.
When a program that is registered with "initializer" directive is executed, the program runs just under the <kernel> domain.
The following is the guideline.

- Scripts that start or terminate daemon programs located under /etc/init.d/ directory.
- Daemon programs that you want to make domain names shorter (for example, httpd and sshd).

Since it is impossible to append to policy automatically for programs that triggers power failure, specify domains that are used by such programs as trusted.
Actual program that involves power failure depends on distributions. In many cases, the final command invoked by shutdown scripts located under /etc/init.d/ directory is the program to trigger power failure.

A shell script is included that performs the operations described above. Create /root/security/exception_policy.txt based on the candidates shown by executing /root/ccstools/make_exception.sh . You have to review the content of the file because automatically generated file may contain redundant or dangerous entries.

### Changes for logrotate

Register domain for /usr/sbin/logrotate as "initializer" in the exception policy because you run logrotate from the command line (not from cron) to learn necessary permissions.

initializer /usr/sbin/logrotate

### Changes for prelink

Jobs that read/write so many programs could be removed from cron jobs.

For example, /etc/cron.daily/prelink for Fedora Core 3 and later reads/writes many programs, and this makes policy files larger. Moreover, it is not desirable to allow read/write permissions to executable files.

I think that it is enough executing /usr/sbin/prelink once after updating packages from the trusted domain, without executing /usr/sbin/prelink everyday from cron. Therefore, you can remove from cron jobs as follows.

mv /etc/cron.daily/prelink /usr/sbin/prelink.cron

### Changes for anacron

Register domain for /usr/sbin/anacron as "initializer" in the exception policy because you run anacron from the command line to learn necessary permissions.

initializer /usr/sbin/anacron

Register domain for /usr/bin/run-parts as "initializer" in the exception policy because anacron runs /usr/bin/run-parts .

initializer /usr/bin/run-parts

### Changes for cron

Register domain for /usr/bin/run-parts as "initializer" in the exception policy because cron runs /usr/bin/run-parts .

initializer /usr/bin/run-parts

Open /etc/crontab and modify to run cron jobs for 5 minutes interval. 1 minute interval is too short to finish previous cron job, therefore you need to make appropriate interval.

Before | After
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly | SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts */5 * * * * root run-parts /etc/cron.hourly */5 * * * * root run-parts /etc/cron.daily */5 * * * * root run-parts /etc/cron.weekly */5 * * * * root run-parts /etc/cron.monthly

Be sure to undo /etc/crontab after you have finished generating policies.

## Changes for Targeted Policy

The /root/security/exception_policy.txt generated by the procedure above is for "Strict Policy". If you want to use TOMOYO Linux for "Targeted Policy", modify /root/security/exception_policy.txt in the following way.

Add the following 3 lines. If /sbin/modprobe and/or /sbin/hotplug are symbolic links, give the dereferenced pathnames.

trust_domain <kernel> /sbin/init trust_domain <kernel> /sbin/modprobe trust_domain <kernel> /sbin/hotplug

Exclude lines that begins with "initializer" directive and that you want to disable Mandatory Access Controls on the program specified with "initializer" directive. For example, if you want to enable Mandatory Access Controls on /usr/sbin/httpd and programs invoked by /usr/sbin/httpd , remove all lines that starts with "initializer" directive but the following 3 lines.

initializer /usr/sbin/httpd initializer /sbin/modprobe initializer /sbin/hotplug

By these steps, /usr/sbin/httpd and programs invoked by /usr/sbin/httpd run in the "<kernel> /usr/sbin/httpd" domain and its child domains and are protected by Mandatory Access Controls. Other programs run in one of the "<kernel> /sbin/init" "<kernel> /sbin/modprobe" "<kernel> /sbin/hotplug" domain and are not protected by Mandatory Access Controls.

# Creating Policy

## Accept Mode

Boot with TOMOYO Linux kernel with the profile number for accept mode to CCS= parameter. Give the parameter "TOMOYO_NOLOAD" to the kernel command line for the first time to skip reading domain policy. If the parameter "TOMOYO_NOLOAD" is given, the domain policy file (domain_policy.txt) won't get loaded. (Therefore, choose TOMOYO Linux kernel with TOMOYO_NOLOAD parameter and the profile number for accept mode to CCS= parameter.)

Do a series of operations you want to allow.

Repeat several times, for all access patterns may not be recorded by single operations.
Also, there are operations that are done only startup and shutdown, repeat reboot for several times.

When you are running with accept mode, you may find messages in the following format.

TOMOYO-WARNING: Domain '<kernel> ...' has so many ACLs to hold. Stopped auto-append mode.

This message tells you that the safeguard for this program is activated to prevent memory consumption and dull response since this program accessed so many files. When the safeguard is activated, file ACLs for that domain are no longer appended automatically.

To deal with this message, you need to edit ACLs manually.
For example, if the following message appeared, you need to reduce the number of file ACLs for <kernel> /usr/sbin/hald using appropriate pathname patterns.

TOMOYO-WARNING: Domain '<kernel> /usr/sbin/hald' has so many ACLs to hold. Stopped auto-append mode.

You can edit policies using /root/ccstools/editpolicy .

### Operations for logrotate

Run logrotate from the command line to learn necessary permissions. To run logrotate jobs regardless of the system clock, use -f option.

/usr/sbin/logrotate -f /etc/logrotate.conf

Repeat several times, for all access patterns may not be recorded by single operations.

### Operations for anacron

Run anacron from the command line to learn necessary permissions. To run anacron jobs regardless of the system clock, use -d -f -n options.

anacron -dfn

Repeat several times, for all access patterns may not be recorded by single operations.

## Updating Exception Policy

Reboot with normal kernel.

Run the following command to find pathnames that are likely temporary, and make appropriate patterns and register in /root/security/exception_policy.txt using "file_pattern" directive.

/root/ccstools/findtemp < /root/security/domain_policy.txt | sort | uniq

Guidelines for temporary pathnames are "Multiple pathnames that differs only last 6 letters", "Multiple pathnames that differs only numerical part" and so on.
An example of patterned pathnames is shown below. These patterned pathnames may not exist or exist in other location depending on the applications installed and their configurations.

- file_pattern /etc/.fstab.hal.\?
- file_pattern /etc/blkid.tab-\?\?\?\?\?\?
- file_pattern /etc/mrtg/mrtg.cfg_l_\$
- file_pattern /root/.emacs.d/auto-save-list/.saves-\$-\*
- file_pattern /root/Mail/inbox/\$
- file_pattern /tmp/auto\?\?\?\?\?\?/
- file_pattern /tmp/autofs.\?\?\?\?\?\?
- file_pattern /tmp/logrotate.\?\?\?\?\?\?
- file_pattern /tmp/logwatch.\*/
- file_pattern /tmp/logwatch.\*/\*
- file_pattern /tmp/makewhatis\?\?\?\?\?\?/
- file_pattern /tmp/makewhatis\?\?\?\?\?\?/w
- file_pattern /tmp/sh-thd-\$
- file_pattern /tmp/spamassassin-\$/
- file_pattern /tmp/spamassassin-\$/.spamassassin/
- file_pattern /tmp/spamassassin-\$/.spamassassin/auto-whitelist\*
- file_pattern /tmp/whatis.\?\?\?\?\?\?
- file_pattern /var/lib/dhcp/dhcpd.leases.\$
- file_pattern /var/lock/autofs.\$
- file_pattern /var/lock/mrtg/mrtg_l_\$
- file_pattern /var/log/ksymoops/\*
- file_pattern /var/log/sa/sa\*
- file_pattern /var/mailman/locks/gate_news.lock.\*
- file_pattern /var/run/gpm\?\?\?\?\?\?

Add "initializer" and "allow_read" if you want to add.

Add "trust_domain" if you want some domains for (for example) maintenances.

## Accept Mode

If you are sure you found all patterns, recreate the domain policy from the beginning. Give the parameter "TOMOYO_NOLOAD" to the kernel command line for the first time to skip reading domain policy.

# Tuning Policy

Reboot with normal Linux kernel.

## Adding from Audit Logs

The file /var/log/tomoyo/reject_log.txt contains the access rejected logs in time-series order. Pick up appropriate range from the file and pass to the filter by running the following command. This filter program sorts access rejected logs by domainname and erases duplicated logs. (In other words, this filter program do sort and uniq for each domain.)

/root/ccstools/sortpolicy < /var/log/tomoyo/reject_log.txt

Decide to add the result or not to add. If you decided to add, add it to /root/security/domain_policy.txt .

## Patterning File Access Permissions

Append access permissions for files that are not necessarily accessed in the accept mode such as WWW contents for WWW service to /root/security/domain_policy.txt .
The following example allows /usr/sbin/httpd to read files in the /var/www/html/ directory.

<kernel> /usr/sbin/httpd 4 /var/www/html/\* 4 /var/www/html/\*/\* 4 /var/www/html/\*/\*/\* 4 /var/www/html/\*/\*/\*/\* 4 /var/www/html/\*/\*/\*/\*/\*

In the same way, modify access permissions for files using patterns that should be grouped. The following example shows /usr/sbin/smbd should handle all log files equally.

Before | After
<kernel> /usr/sbin/smbd 2 /var/log/samba/host1.log 2 /var/log/samba/host2.log 2 /var/log/samba/host3.log 2 /var/log/samba/host4.log 2 /var/log/samba/host5.log | <kernel> /usr/sbin/smbd 2 /var/log/samba/\*.log

## Patterning Network Access Permissions

There are programs (for example, portmap) that requests privileged ports (local port numbers less that 1024) at random. It is impossible to know all local ports that might be used by such applications using accept mode. Repeat running such programs for several times using accept mode, guess the range of local ports such program would request, and grant network access permissions using range.
An example is shown below. Don't copy the following permissions because the range may vary depending on distributions and configurations.

<kernel> /sbin/portmap allow_bind TCP/0 allow_bind TCP/111 allow_bind TCP/600-1023 allow_bind UDP/0 allow_bind UDP/111 allow_bind UDP/600-1023 allow_connect UDP/32768-65535 allow_connect UDP/600-1023 <kernel> /sbin/rpc.statd allow_bind TCP/0 allow_bind TCP/600-1023 allow_bind UDP/0 allow_bind UDP/600-1023 allow_connect UDP/111 <kernel> /usr/sbin/rpc.mountd allow_bind TCP/0 allow_bind TCP/600-1023 allow_bind UDP/0 allow_bind UDP/600-1023 allow_connect UDP/111 <kernel> /usr/sbin/rpc.nfsd allow_capability inet_tcp_create allow_capability use_inet_udp allow_connect UDP/111 allow_connect UDP/32768-65535 <kernel> /usr/sbin/rpc.rquotad allow_bind TCP/600-1023 allow_bind UDP/600-1023 allow_connect UDP/111 <kernel> /usr/sbin/rpcinfo allow_bind UDP/600-1023 allow_connect UDP/111 allow_connect UDP/2049 <kernel> /usr/sbin/xinetd allow_bind TCP/0 allow_bind UDP/69 allow_bind UDP/600-1023 allow_connect UDP/111

If you don't need services like NFS or NIS that needs RPC, you should disable such services.

Similarly, make patterns for "allow_network" directives. Don't copy the following permissions.

Before | After
<kernel> /usr/sbin/sshd allow_network TCP accept 0:0:0:0:0:0:0:1 43768 allow_network TCP accept 0:0:0:0:0:ffff:a00:1 35086 allow_network TCP accept 0:0:0:0:0:ffff:a00:a1 47590 allow_network TCP accept 10.0.0.10 56709 allow_network TCP accept 10.0.0.200 16384 | <kernel> /usr/sbin/sshd allow_network TCP accept 0:0:0:0:0:0:0:1 1024-65535 allow_network TCP accept 0:0:0:0:0:ffff:a00:1-0:0:0:0:0:ffff:a00:ff 1024-65535 allow_network TCP accept 10.0.0.1-10.0.0.255 1024-65535

## Add conditions to ACLs

TOMOYO Linux 1.2 supports conditional ACLs. By using this feature, you can control system's user ID based access control.

If you want to protect non-anonymous FTP service, by adding conditions in the following manner, you can forbid access to directories outside the user's home directory. To reduce damages when it is cracked, it is recommended that you should expose directories only under specific (such as "ftp") directory rather than exposing whole of home directories. If you use vsftpd, you can give like the following way.

Before
<kernel> /usr/sbin/vsftpd 6 /home/\*/ftp/\* 6 /home/\*/ftp/\*/\* 6 /home/\*/ftp/\*/\*/\* 6 /home/\*/ftp/\*/\*/\*/\* allow_mkdir /home/\*/ftp/\*/ allow_mkdir /home/\*/ftp/\*/\*/ allow_mkdir /home/\*/ftp/\*/\*/\*/ allow_rmdir /home/\*/ftp/\*/ allow_rmdir /home/\*/ftp/\*/\*/ allow_rmdir /home/\*/ftp/\*/\*/\*/ allow_create /home/\*/ftp/\* allow_create /home/\*/ftp/\*/\* allow_create /home/\*/ftp/\*/\*/\* allow_create /home/\*/ftp/\*/\*/\*/\* allow_truncate /home/\*/ftp/\* allow_truncate /home/\*/ftp/\*/\* allow_truncate /home/\*/ftp/\*/\*/\* allow_truncate /home/\*/ftp/\*/\*/\*/\* allow_unlink /home/\*/ftp/\* allow_unlink /home/\*/ftp/\*/\* allow_unlink /home/\*/ftp/\*/\*/\* allow_unlink /home/\*/ftp/\*/\*/\*/\* allow_rename /home/\*/ftp/\* /home/\*/ftp/\* allow_rename /home/\*/ftp/\*/\* /home/\*/ftp/\*/\* allow_rename /home/\*/ftp/\*/\*/\* /home/\*/ftp/\*/\*/\* allow_rename /home/\*/ftp/\*/\*/\*/\* /home/\*/ftp/\*/\*/\*/\* allow_rename /home/\*/ftp/\*/ /home/\*/ftp/\*/ allow_rename /home/\*/ftp/\*/\*/ /home/\*/ftp/\*/\*/ allow_rename /home/\*/ftp/\*/\*/\*/ /home/\*/ftp/\*/\*/\*/

After
<kernel> /usr/sbin/vsftpd 6 /home/\*/ftp/\* if task.uid=path1.uid 6 /home/\*/ftp/\*/\* if task.uid=path1.uid 6 /home/\*/ftp/\*/\*/\* if task.uid=path1.uid 6 /home/\*/ftp/\*/\*/\*/\* if task.uid=path1.uid allow_mkdir /home/\*/ftp/\*/ if task.uid=path1.parent.uid allow_mkdir /home/\*/ftp/\*/\*/ if task.uid=path1.parent.uid allow_mkdir /home/\*/ftp/\*/\*/\*/ if task.uid=path1.parent.uid allow_rmdir /home/\*/ftp/\*/ if task.uid=path1.uid allow_rmdir /home/\*/ftp/\*/\*/ if task.uid=path1.uid allow_rmdir /home/\*/ftp/\*/\*/\*/ if task.uid=path1.uid allow_create /home/\*/ftp/\* if task.uid=path1.parent.uid allow_create /home/\*/ftp/\*/\* if task.uid=path1.parent.uid allow_create /home/\*/ftp/\*/\*/\* if task.uid=path1.parent.uid allow_create /home/\*/ftp/\*/\*/\*/\* if task.uid=path1.parent.uid allow_truncate /home/\*/ftp/\* if task.uid=path1.uid allow_truncate /home/\*/ftp/\*/\* if task.uid=path1.uid allow_truncate /home/\*/ftp/\*/\*/\* if task.uid=path1.uid allow_truncate /home/\*/ftp/\*/\*/\*/\* if task.uid=path1.uid allow_unlink /home/\*/ftp/\* if task.uid=path1.uid allow_unlink /home/\*/ftp/\*/\* if task.uid=path1.uid allow_unlink /home/\*/ftp/\*/\*/\* if task.uid=path1.uid allow_unlink /home/\*/ftp/\*/\*/\*/\* if task.uid=path1.uid allow_rename /home/\*/ftp/\* /home/\*/ftp/\* if task.uid=path1.parent.uid task.uid=path2.parent.uid allow_rename /home/\*/ftp/\*/\* /home/\*/ftp/\*/\* if task.uid=path1.parent.uid task.uid=path2.parent.uid allow_rename /home/\*/ftp/\*/\*/\* /home/\*/ftp/\*/\*/\* if task.uid=path1.parent.uid task.uid=path2.parent.uid allow_rename /home/\*/ftp/\*/\*/\*/\* /home/\*/ftp/\*/\*/\*/\* if task.uid=path1.parent.uid task.uid=path2.parent.uid allow_rename /home/\*/ftp/\*/ /home/\*/ftp/\*/ if task.uid=path1.parent.uid task.uid=path2.parent.uid allow_rename /home/\*/ftp/\*/\*/ /home/\*/ftp/\*/\*/ if task.uid=path1.parent.uid task.uid=path2.parent.uid allow_rename /home/\*/ftp/\*/\*/\*/ /home/\*/ftp/\*/\*/\*/ if task.uid=path1.parent.uid task.uid=path2.parent.uid

If you want to protect Samba service, by adding conditions in the following manner, you can forbid access to directories outside the user's home directory. To reduce damages when it is cracked, it is recommended that you should expose directories only under specific (such as "samba") directory rather than exposing whole of home directories.

Before
<kernel> /usr/sbin/smbd 6 /home/\*/samba/\* 6 /home/\*/samba/\*/\* 6 /home/\*/samba/\*/\*/\* 6 /home/\*/samba/\*/\*/\*/\* allow_mkdir /home/\*/samba/\*/ allow_mkdir /home/\*/samba/\*/\*/ allow_mkdir /home/\*/samba/\*/\*/\*/ allow_rmdir /home/\*/samba/\*/ allow_rmdir /home/\*/samba/\*/\*/ allow_rmdir /home/\*/samba/\*/\*/\*/ allow_create /home/\*/samba/\* allow_create /home/\*/samba/\*/\* allow_create /home/\*/samba/\*/\*/\* allow_create /home/\*/samba/\*/\*/\*/\* allow_truncate /home/\*/samba/\* allow_truncate /home/\*/samba/\*/\* allow_truncate /home/\*/samba/\*/\*/\* allow_truncate /home/\*/samba/\*/\*/\*/\* allow_unlink /home/\*/samba/\* allow_unlink /home/\*/samba/\*/\* allow_unlink /home/\*/samba/\*/\*/\* allow_unlink /home/\*/samba/\*/\*/\*/\* allow_rename /home/\*/samba/\* /home/\*/samba/\* allow_rename /home/\*/samba/\*/\* /home/\*/samba/\*/\* allow_rename /home/\*/samba/\*/\*/\* /home/\*/samba/\*/\*/\* allow_rename /home/\*/samba/\*/\*/\*/\* /home/\*/samba/\*/\*/\*/\* allow_rename /home/\*/samba/\*/ /home/\*/samba/\*/ allow_rename /home/\*/samba/\*/\*/ /home/\*/samba/\*/\*/ allow_rename /home/\*/samba/\*/\*/\*/ /home/\*/samba/\*/\*/\*/

After
<kernel> /usr/sbin/smbd 6 /home/\*/samba/\* if task.euid=path1.uid 6 /home/\*/samba/\*/\* if task.euid=path1.uid 6 /home/\*/samba/\*/\*/\* if task.euid=path1.uid 6 /home/\*/samba/\*/\*/\*/\* if task.euid=path1.uid allow_mkdir /home/\*/samba/\*/ if task.euid=path1.parent.uid allow_mkdir /home/\*/samba/\*/\*/ if task.euid=path1.parent.uid allow_mkdir /home/\*/samba/\*/\*/\*/ if task.euid=path1.parent.uid allow_rmdir /home/\*/samba/\*/ if task.euid=path1.uid allow_rmdir /home/\*/samba/\*/\*/ if task.euid=path1.uid allow_rmdir /home/\*/samba/\*/\*/\*/ if task.euid=path1.uid allow_create /home/\*/samba/\* if task.euid=path1.parent.uid allow_create /home/\*/samba/\*/\* if task.euid=path1.parent.uid allow_create /home/\*/samba/\*/\*/\* if task.euid=path1.parent.uid allow_create /home/\*/samba/\*/\*/\*/\* if task.euid=path1.parent.uid allow_truncate /home/\*/samba/\* if task.euid=path1.uid allow_truncate /home/\*/samba/\*/\* if task.euid=path1.uid allow_truncate /home/\*/samba/\*/\*/\* if task.euid=path1.uid allow_truncate /home/\*/samba/\*/\*/\*/\* if task.euid=path1.uid allow_unlink /home/\*/samba/\* if task.euid=path1.uid allow_unlink /home/\*/samba/\*/\* if task.euid=path1.uid allow_unlink /home/\*/samba/\*/\*/\* if task.euid=path1.uid allow_unlink /home/\*/samba/\*/\*/\*/\* if task.euid=path1.uid allow_rename /home/\*/samba/\* /home/\*/samba/\* if task.euid=path1.parent.uid task.euid=path2.parent.uid allow_rename /home/\*/samba/\*/\* /home/\*/samba/\*/\* if task.euid=path1.parent.uid task.euid=path2.parent.uid allow_rename /home/\*/samba/\*/\*/\* /home/\*/samba/\*/\*/\* if task.euid=path1.parent.uid task.euid=path2.parent.uid allow_rename /home/\*/samba/\*/\*/\*/\* /home/\*/samba/\*/\*/\*/\* if task.euid=path1.parent.uid task.euid=path2.parent.uid allow_rename /home/\*/samba/\*/ /home/\*/samba/\*/ if task.euid=path1.parent.uid task.euid=path2.parent.uid allow_rename /home/\*/samba/\*/\*/ /home/\*/samba/\*/\*/ if task.euid=path1.parent.uid task.euid=path2.parent.uid allow_rename /home/\*/samba/\*/\*/\*/ /home/\*/samba/\*/\*/\*/ if task.euid=path1.parent.uid task.euid=path2.parent.uid

If you want to protect SSH service, by adding conditions in the following manner, you can forbid login as user "root".

Before | After
<kernel> /usr/sbin/sshd 1 /bin/bash | <kernel> /usr/sbin/sshd 1 /bin/bash if task.uid!=0 task.euid!=0

See Conditional permission for available conditions.

## Permissive Mode

Boot with TOMOYO Linux kernel with the profile number for permissive mode to CCS= parameter.

Check that error messages don't appear when you operate you want to allow.

If the system works properly, the installation of TOMOYO Linux is done.

# Production State

## Enforce mode

Boot with TOMOYO Linux kernel with the profile number for enforce mode to CCS= parameter.