TOMOYO Linux Install manual

Last modified: $Date: 2006-11-25 10:18:46 +0900 (Sat, 25 Nov 2006) $

Index


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

TOMOYO Linux provides some binary kernel packages. If you want to use binary kernel packages, download and install.

RedHat Linux 9 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-2.4.20-46.9.legacy_tomoyo_1.2.i386.rpm
Fedora Core 3 (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-2.6.12-2.3.legacy_FC3_tomoyo_1.2.i586.rpm
Fedora Core 4 (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-2.6.17-1.2142_FC4_tomoyo_1.2.i586.rpm
Fedora Core 5 (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-2.6.18-1.2200_FC5_tomoyo_1.2.i586.rpm
Fedora Core 6 (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-2.6.18-1.2798_tomoyo_1.2.i586.rpm
CentOS 4.4 (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-2.6.9-42.0.3.EL_tomoyo_1.2.i586.rpm
Debian Sarge (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-image-2.4.27-10sarge4-ccs_1.2_i586.deb
http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-image-2.6.8-16sarge5-ccs_1.2_i586.deb
OpenSUSE 10.1 (80586 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/kernel-default-2.6.16.21-0.25_tomoyo_1.2.i586.rpm

If the CPU architecture differs or you want to customize kernel configuration, you need to compile kernel. To compile kernel, see TOMOYO Linux kernel compilation.

Install Tool

TOMOYO Linux provides some pre-compiled tools. If you want to use pre-compiled tools, download and extract under /root/ directory.

RedHat Linux 9 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-RHL9.tar.gz
Fedora Core 3 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-FC3.tar.gz
Fedora Core 4 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-FC4.tar.gz
Fedora Core 5 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-FC5.tar.gz
Fedora Core 6 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-FC6.tar.gz
CentOS 4.4 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-CentOS4.4.tar.gz
Debian Sarge (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-Sarge.tar.gz
OpenSUSE 10.1 (80386 and later) http://osdn.dl.sourceforge.jp/tomoyo/21518/ccs-tools-1.2-i386-SUSE10.1.tar.gz

If the CPU architecture differs, you need to compile tools. To compile tools, run the following commands.

# Download source of tools for TOMOYO Linux.
wget http://osdn.dl.sourceforge.jp/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.

Normal Authentication

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.

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

Embedding User

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.

Embedding Role

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
BeforeAfter

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
BeforeAfterBeforeAfter


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.

NameControlAccept mode supported
MAC_FOR_FILEFile AccessYes
MAC_FOR_CAPABILITY::inet_tcp_createUse of TCP socketYes
MAC_FOR_CAPABILITY::inet_tcp_listenListening TCP socketYes
MAC_FOR_CAPABILITY::inet_tcp_connectConnecting TCP socketYes
MAC_FOR_CAPABILITY::use_inet_udpUse of UDP socketYes
MAC_FOR_CAPABILITY::use_inet_ipUse of RAW socketYes
MAC_FOR_CAPABILITY::use_routeUse of ROUTE socketYes
MAC_FOR_CAPABILITY::use_packetUse of PACKET socketYes
MAC_FOR_CAPABILITY::use_kernel_moduleUse of kernel modulesYes
MAC_FOR_CAPABILITY::create_fifoCreating FIFOYes
MAC_FOR_CAPABILITY::create_block_devCreating block device fileYes
MAC_FOR_CAPABILITY::create_char_devCreating character device fileYes
MAC_FOR_CAPABILITY::create_unix_socketCreating UNIX domain socketYes
MAC_FOR_CAPABILITY::SYS_MOUNTMounting filesystemYes
MAC_FOR_CAPABILITY::SYS_UMOUNTUnmounting filesystemYes
MAC_FOR_CAPABILITY::SYS_REBOOTRebooting the systemYes
MAC_FOR_CAPABILITY::SYS_CHROOTChanging the "/" directoryYes
MAC_FOR_CAPABILITY::SYS_KILLSending signalsYes
MAC_FOR_CAPABILITY::SYS_VHANGUPUse of vhangupYes
MAC_FOR_CAPABILITY::SYS_TIMESetting system's clockYes
MAC_FOR_CAPABILITY::SYS_NICESetting process priorityYes
MAC_FOR_CAPABILITY::SYS_SETHOSTNAMESetting hostname or domainnameYes
MAC_FOR_CAPABILITY::SYS_LINKCreating hard linkYes
MAC_FOR_CAPABILITY::SYS_SYMLINKCreating symbolic linkYes
MAC_FOR_CAPABILITY::SYS_RENAMERenaming fileYes
MAC_FOR_CAPABILITY::SYS_UNLINKDeleting fileYes
MAC_FOR_CAPABILITY::SYS_CHMODChanging file's permissionsYes
MAC_FOR_CAPABILITY::SYS_CHOWNChanging file's owner or groupYes
MAC_FOR_CAPABILITY::SYS_IOCTLUse of ioctlYes
MAC_FOR_CAPABILITY::SYS_KEXEC_LOADLoading new kernelYes
MAC_FOR_NETWORKIP addresses and port numbersYes
MAC_FOR_BINDPORTLocal port numbersYes
MAC_FOR_CONNECTPORTRemote port numbersYes
MAC_FOR_SIGNALCombination of signal numbers and destination domainsYes
DENY_CONCEAL_MOUNTForbid mount requests that hides an existing mountNo
RESTRICT_CHROOTEnable restrictions for chroot directoriesYes
RESTRICT_MOUNTEnable restrictions for mount parametersYes
RESTRICT_UNMOUNTForbid unmount requests for specified directoriesNo
DENY_PIVOT_ROOTForbid pivot_root requestsNo
RESTRICT_AUTOBINDForbid assigning specific local port numbers for automatic local port assignment functionNo
TRACE_READONLYDump Canonicalized Pathname that write requests failed due to read only filesystem-
MAX_ACCEPT_FILESLimits the max number of file ACL entries that are automatically appended during accept mode-
MAX_GRANT_LOGLimits the max number of grant logs that the kernel can hold-
MAX_REJECT_LOGLimits the max number of reject logs that the kernel can hold-
TOMOYO_VERBOSEDump domain policy violation messages to syslog-
MAX_ENFORCE_GRACEWait before rejecting access request when the request violates policy in enforce mode-

You can give the following values for TRACE_READONLY and RESTRICT_AUTOBIND

ValueMeaning
0Off. Works as if regular kernel.
1On.

You can give the following values for MAX_ACCEPT_FILES

ValueMeaning
any integerThe 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

ValueMeaning
any integerThe 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

ValueMeaning
0Don't dump domain policy violation messages.
1Dump domain policy violation messages.

You can give the following values for MAX_ENFORCE_GRACE

ValueMeaning
any integerThe 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.

ValueMeaning
0Disabled. Works as if regular kernel.
1Accept mode. Not rejected if the request violates policy. Automatically appended to policy.
2Permissive mode. Not rejected if the request violates policy. Not appended to policy automatically.
3Enforce 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.

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.

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.

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.

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

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.

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

BeforeAfter
<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".

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