<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta http-equiv="Content-Style-Type" content="text/css">
<title>The world of TOMOYO Linux&nbsp;&nbsp;The fourth installment: "Let's tune policy."</title>
<link rel="stylesheet" href="http://tomoyo.sourceforge.jp/tomoyo.css" media="all" type="text/css">
</head>
<body>
<p style="text-align:right;"><a href="tutorial-4.html.ja">Japanese Page</a></p>
<p style="text-align:right;">Last modified: $Date: 2013-03-09 12:24:36 +0900 (Sat, 09 Mar 2013) $</p>

<h1>The world of TOMOYO Linux<br>The fourth installment: "Let's tune policy."</h1>

<h2>Contents of this installment.</h2>

<p>In this installment, I explain how to tune policy which is essential for fully mastering TOMOYO Linux and functionality for assisting policy tuning.</p>

<h2>About functionality for assisting policy modification</h2>

<p>If you are using secure OS, processes being hijacked or administrator's privileges being stolen won't immediately cause fatal damage. Thus, you may feel easier than normal OS for instantly updating systems, but there is no justification for overconfidence. You should apply updates and keep your systems at the best condition. Regarding OS with mandatory access control functionality, the system's behavior is restricted by policy configuration defined by administrator. Therefore, you may need to adjust policy configuration in order to keep software work properly when program's dependency has changed due to software updates. In TOMOYO Linux, administrators define policy configuration by themselves. Thus, administrators modify policy configuration by themselves. In this installment, I explain functionality for assisting adjusting policy configuration which will be needed by updating softwares.</p>

<p>TOMOYO Linux provides two types of enforcing mode. The former (Fig. 1) type is that access requests that violated policy in enforcing mode are immediately rejected. The latter (Fig. 2) type is that access requests that violated policy in enforcing mode are judged by administrator's interactive operation. The latter type is useful when policy violation occurred in enforcing mode or when you need to adjust policy by software updates.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 1&nbsp;&nbsp;Reject immediately requests which violate policy<br>
<img src="tutorial/fig-4-1-en.png" alt="fig-4-1-en.png" width="800" height="480">
</td></tr>
</table>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 2&nbsp;&nbsp;Interactively judge requests which violate policy<br>
<img src="tutorial/fig-4-2-en.png" alt="fig-4-2-en.png" width="800" height="480">
</td></tr>
</table>

<h3>Tools for using this functionality</h3>

<p>TOMOYO Linux provides programs listed in Fig. 3 for assisting adjusting policy configuration.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 3&nbsp;&nbsp;Programs for managing TOMOYO Linux<br>
<table border="1" summary="fig">
<tr><td>Name of program</td><td>Role of program</td></tr>
<tr><td>ccs-queryd</td><td>Interactively grant access requests</td></tr>
</table>
</td></tr>
</table>

<h3>Operation example on console login session</h3>

<p>I explain using restricting login session as an example. To avoid being locked out by operation errors, I use "example" user account. Also, I switch "root" user and "example" user by switching console windows. You can switch console windows using "ALT" + one of "F1"&sdot;&sdot;&sdot;"F6" keys. Open "window 1" by pressing "ALT" + "F1" keys, and login as "root" user. Assign different shells for "root" user and "example" user. This is for creating different domains for these users by using different login shells, and for applying restriction against specific login shell's domains. In this series, I'm using /bin/bash for "root" user's shell. Thus, I assign /bin/tcsh for "example" user's shell. (Fig. 4)</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 4&nbsp;&nbsp;Assign /bin/tcsh to "example" user
<pre>
# usermod -s /bin/tcsh example
</pre>
</td></tr>
</table>

<p>Next, open "window 2" by pressing "ALT" + "F2" keys, and login as "example" user. If you are using CentOS 5, the domain for console login will be "&lt;kernel&gt; /sbin/mingetty /bin/login /bin/tcsh". (If you login via /usr/sbin/sshd , the domain will be "&lt;kernel&gt; /usr/sbin/sshd /bin/tcsh".) Switch to "window1" and assign a profile for enforcing mode (i.e. profile 3) to domains for "example" user's login shell. (Fig. 5)</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 5&nbsp;&nbsp;Assign a profile for enforcing mode example to "example" user's shell domain (window 2)
<pre>
# /usr/sbin/ccs-setprofile -r 3 '&lt;kernel&gt; /sbin/mingetty /bin/login /bin/tcsh'
</pre>
</td></tr>
</table>

<p>Now, almost everything is forbidden for "example" user's shell (i.e. "window 2"). (Fig. 6)</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 6&nbsp;&nbsp;Verify the result of applying Fig. 5
<pre>
$ ls
/bin/ls: Operation not permitted.
$ cat /etc/passwd
/bin/cat: Operation not permitted.
</pre>
</td></tr>
</table>

<p>By using ccs-queryd command (Fig. 7), you can ask for administrator's decision when a process which belongs to domains with a profile for enforcing mode requested an access that violated policy instead of immediately reject the access. This feature is specific to TOMOYO Linux, not available in SELinux or AppArmor.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 7&nbsp;&nbsp;Executing ccs-queryd command
<pre>
# /usr/sbin/ccs-queryd
</pre>
</td></tr>
</table>

<p>Switch to "window 2" and request for execution of /bin/ls command. (Fig. 8)</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 8&nbsp;&nbsp;Executing ls command
<pre>
$ /bin/ls
</pre>
</td></tr>
</table>

<p>Last time, the request was rejected immediately. But this time, it is stopped instead of rejected. Switch to "window 1" while keeping this state, and you will see prompt like Fig. 9.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 9&nbsp;&nbsp;Prompt shown on window 1 after executing Fig. 8
<pre>
#2011/01/17 03:51:10# profile=3 mode=enforcing granted=no (global-pid=3523) task={ pid=3523 ppid=3468 uid=502 gid=502 euid=502 egid=502 suid=502 sgid=502 fsu
id=502 fsgid=502 type!=execute_handler } path1={ uid=0 gid=0 ino=951094 major=8 minor=1 perm=0755 type=file } path1.parent={ uid=0 gid=0 ino=917505 perm=0755
 } exec={ realpath="/bin/ls" argc=1 envc=21 argv[]={ "/bin/ls" } envp[]={ "HOME=/home/example" "PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R
6/bin" "SHELL=/bin/tcsh" "TERM=linux" "MAIL=/var/spool/mail/example" "LOGNAME=example" "HOSTTYPE=i386-linux" "VENDOR=intel" "OSTYPE=linux" "MACHTYPE=i386" "S
HLVL=1" "PWD=/home/example" "USER=example" "GROUP=example" "HOST=tomoyo" "HOSTNAME=tomoyo" "INPUTRC=/etc/inputrc" "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=0
1;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:*.c
pio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:" "G_BROKEN_FILENAMES=1" "LANG=en_US.UTF-8" "LESSOPEN=|/usr/bin
/lesspipe.sh\040%s" } }
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/tcsh
file execute /bin/ls
Allow? ('Y'es/'N'o/'R'etry/'S'how policy/'A'dd to policy and retry):
</pre>
</td></tr>
</table>

<p>The first line shows information about the process which requested an access that violated policy and about the file the process is requesting. The second line shows domainname of domain which the process which requested an access that violated policy belongs to. The third line shows the access that violated policy. This way the request is displayed in the same syntax with domain policy. If you press "Y" key here, the access is granted and you will see prompt like Fig. 10. If you press "N" key here, the access is rejected.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 10&nbsp;&nbsp;Prompt for next policy violation event
<pre>
#2011/01/17 03:51:50# profile=3 mode=enforcing granted=no (global-pid=3523) task={ pid=3523 ppid=3468 uid=502 gid=502 euid=502 egid=502 suid=502 sgid=502 fsu
id=502 fsgid=502 type!=execute_handler } path1={ uid=0 gid=0 ino=328251 major=8 minor=1 perm=0644 type=file } path1.parent={ uid=0 gid=0 ino=327965 perm=0755
 }
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/tcsh /bin/ls
file read /etc/selinux/config
Allow? ('Y'es/'N'o/'R'etry/'S'how policy/'A'dd to policy and retry):
</pre>
</td></tr>
</table>

<p>Since the domain for /bin/ls was just created, no permissions are given to this domain. Read the prompt and carefully judge whether the access should be granted or not and answer. If you press "A" key, you can add permission to domain policy (after editing the permission if you needed) and retry the request. For example, if you want to allow not only /etc/passwd but also all /etc/\* except /etc/\*shadow\* , change /etc/passwd to /etc/\*\-\*shadow\* and then press "Enter" key.</p>

<p>To terminate ccs-queryd program, press "CTRL" + "C" keys.</p>

<h3>Precautions when using ccs-queryd command</h3>

<p>You have to be aware two things when using ccs-queryd command. One is that you must not unconditionally grant the request. The cause of policy violation may be attacks by malicious users. If you grant access requests caused by attacks by malicious users, the protection by mandatory access control becomes invalid. The other is that if "ccs-queryd" is running, the access requests that violated policy are kept pending until administrator answers. Thus, never leave or logout while "ccs-queryd" is running.</p>

<h3>An operation example for actual service</h3>

<p>Please see <a href="http://tomoyo.sourceforge.jp/1.8/phase-5.html.en#5.2">Handling policy violation in real-time</a>.</p>

<h2>About removing garbage from policy configuration</h2>

<h3>Tools for using this functionality</h3>

<p>TOMOYO Linux provides programs listed in Fig. 11 for assisting removing unnecessary permissions from policy configuration.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 11&nbsp;&nbsp;Programs for managing TOMOYO Linux<br>
<table border="1" summary="fig">
<tr><td>Name of program</td><td>Role of program</td></tr>
<tr><td>ccs-findtemp</td><td>Detect nonexistent pathnames</td></tr>
<tr><td>ccs-domainmatch</td><td>Find domains which contain specified permissions</td></tr>
</table>
</td></tr>
</table>

<p>By using these programs, you can detect and remove redundant pathnames (e.g. not yet patternized temporary files and library files deleted by software updates).</p>

<h3>An operation example on console session</h3>

<p>To handily try this functionality, I explain using console session. Do operations listed in Fig. 12 in learning mode.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 12&nbsp;&nbsp;Operations for learning mode
<pre>
# touch /tmp/abc12345
# rm -f /tmp/abc12345
</pre>
</td></tr>
</table>

<p>By doing these operations, touch command and rm command learned access to /tmp/abc12345 but the file /tmp/abc12345 no longer exists. If these operations were redundant, redundant permissions (or garbage) which won't be used are left. Pathnames which exists in policy configuration but do not exist are likely either used as temporary files or deleted by software updates. By using ccs-findtemp command, pathnames which exists in policy configuration but do not exist are printed. Note that Fig. 13 shows only /tmp/abc12345 but other pathnames will be also printed for actual systems.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 13&nbsp;&nbsp;Executing ccs-findtemp command
<pre>
# /usr/sbin/ccs-findtemp &lt; /proc/ccs/domain_policy
/tmp/abc12345
# /usr/sbin/ccs-findtemp --with-domainname &lt; /proc/ccs/domain_policy
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/bash /bin/touch
/tmp/abc12345
/tmp/abc12345
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/bash /bin/rm
/tmp/abc12345
# /usr/sbin/ccs-domainmatch /tmp/abc12345
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/bash /bin/touch
file create /tmp/abc12345 0666
file write /tmp/abc12345
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/bash /bin/rm
file unlink /tmp/abc12345
</pre>
</td></tr>
</table>

<p>By executing ccs-domainmatch command with pathnames printed by ccs-findtemp command as command line arguments, domainnames which contains permission against command line arguments are printed. If you think the permission is redundant, you can execute ccs-editpolicy command and go to appropriate domains and delete the permission.</p>

<h2>Saving access logs</h2>

<p>TOMOYO Linux can generate "Log of access requests which did not violate policy" (in short, "access granted log") and "Log of access requests which violated policy" (in short, "access rejected log"). You can use a daemon program ccs-auditd for reading "access granted log" and "access rejected log" from kernel and writing to files on disk.</p>

<h3>Let's save access logs</h3>

<p>Next, append a line in Fig. 14 to /etc/rc.d/rc.local .</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 14&nbsp;&nbsp;Contents to append to /etc/rc.d/rc.local
<pre>
/usr/sbin/ccs-auditd
</pre>
</td></tr>
</table>

<p>Then, create /etc/logrotate.d/tomoyo with the contents in Fig. 15 in order to let logrotate command rotate automatically. Be sure to specify "nocreate" option, or access logs won't be saved after the first rotation.</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 15&nbsp;&nbsp;Configure logrotate to rotate access logs ( /etc/logrotate.d/tomoyo )
<pre>
/var/log/tomoyo/*.log {
    weekly
    rotate 9
    missingok
    notifempty
    nocreate
}
</pre>
</td></tr>
</table>

<p>If you don't want to save access logs, you can specify "PREFERENCE={ max_audit_log=0 }" in the profiles and you don't need to run ccs-auditd command.</p>

<h3>Let's browse access logs</h3>

<p>Access logs are in the form of domain policy (Fig. 16). Therefore you can append access logs to /etc/ccs/domain_policy.conf .</p>

<table border="1" summary="fig">
<tr><td>
&diams; Fig. 16&nbsp;&nbsp;Contents of access logs ( /var/log/tomoyo/reject_003.log )
<pre>
# cat /var/log/tomoyo/reject_003.log
#2011/01/17 04:23:43# profile=3 mode=enforcing granted=no (global-pid=4793) task={ pid=4793 ppid=4759 uid=500 gid=500 euid=500 egid=500 suid=500 sgid=500 fsuid=500 fsgid=500 type!=execute_handler } path1={ uid=501 gid=501 ino=786913 major=8 minor=1 perm=0664 type=file } path1.parent={ uid=0 gid=0 ino=786433 perm=01777 }
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/bash /bin/cat
file read /tmp/testfile2

#2011/01/17 04:23:51# profile=3 mode=enforcing granted=no (global-pid=4847) task={ pid=4847 ppid=4814 uid=501 gid=501 euid=501 egid=501 suid=501 sgid=501 fsuid=501 fsgid=501 type!=execute_handler } path1={ uid=500 gid=500 ino=786912 major=8 minor=1 perm=0664 type=file } path1.parent={ uid=0 gid=0 ino=786433 perm=01777 }
&lt;kernel&gt; /sbin/mingetty /bin/login /bin/bash /bin/cat
file read /tmp/testfile1
</pre>
</td></tr>
</table>

<p>Access logs contain information such as process's credentials (e.g. UID) in addition to requested pathnames. This information can be used for specifying conditional access control list which I explain in the next installment.</p>

<h2>Trailer</h2>

<p>In this installment, I explained how to tune policy. In the next installment, I explain conditional access control list. Don't miss it!</p>

<p><a href="tutorial-3.html.en">Go back to the third installment.</a>&nbsp;&nbsp;<a href="tutorial-5.html.en">Proceed to the fifth installment.</a></p>

<hr>

<p><a href="index.html.en#tutorial">Return to index page.</a></p>
<p><a href="http://sourceforge.jp/"><img src="http://sourceforge.jp/sflogo.php?group_id=1973" width="96" height="31" alt="sflogo.php" title="SourceForge.jp"></a></p>
</body>
</html>
