Info: Version 1.3 is available.

TOMOYO Linux Maintenance manual

Last modified: $Date: 2011-07-01 13:55:23 +0900 (Fri, 01 Jul 2011) $

Notes for updating packages

Since the behavior of the system is restricted by policy, you may need to update policy when you update packages.

You need to update policy in the following cases.

The ideal way to update policy is to rebuild from the scratch using accept mode. But it is not desirable to change from enforce mode to other mode if the system has once entered in production state. Suppose MAC could support per-application enforce mode, the MAC becomes useless if an application that is not running in enforce mode was cracked. For example, the whole system becomes vulnerable if only HTTP server application is running in accept mode to rebuild policy for the application. So, in TOMOYO Linux, updating policy is done while the system is running in enforce mode.

TOMOYO Linux includes tools that helps administrators update policy while the system is running in enforce mode. By using these tools, you can continue running the system without rebuilding from the scratch using accept mode if the modification is trivial. But note that these tools can not always support every cases and the result of updated policy is not always the optimized.

Preparation

Make sure the following lines are included in /root/security/manager.txt . If not, add the following lines and reboot.

/root/ccstools/ld-watch
/root/ccstools/ccs-queryd

Procedure

Open three windows and enter into the trusted domains. Hereafter, this manual refers these windows as "Window-1", "Window-2" and "Window-3".

First, switch to Window-1. And switch the system state from "reject immediately if the policy violation occurs" to "don't reject immediately if the policy violation occurs but wait for administrator's decision". The example below sets 60 seconds.

/root/ccstools/setlevel MAX_ENFORCE_GRACE=60

Start the following command.

/root/ccstools/ccs-queryd

The ccs-queryd detects policy violation and displays the access request. You can tell the system whether the access request should be granted (or granted and policy should be appended to grant the access request) or rejected after you validate the access request.

Never grant access requests unconditionally. The cause of policy violation is not always updating packages, but may by malicious requests by attackers. If you grant access requests caused by malicious requests by attackers, the system gets intruded.

If you didn't give the judge within MAX_ENFORCE_GRACE seconds from the time of access violation, the access request is rejected. So, you should give large enough value for MAX_ENFORCE_GRACE. You should be careful the location of windows so that you don't miss the messages has appeared, for you need to give the judge within MAX_ENFORCE_GRACE seconds from the time of access violation.

Next, start the following command at Window-2.

/root/ccstools/ld-watch

The ld-watch automatically appends shared libraries to exception policy using "allow_read" directive when the location of shared libraries in /etc/ld.so.cache has changed. By using ld-watch, you can avoid errors "unable to start applications because shared libraries are unreadable" when the pathnames of shared libraries accessed by general programs has changed.

Next, switch to Window-3, and run the commands for updating packages.

If you use "yum", run "you update". If you use "apt", run "apt-get update" and "apt-get upgrade".

Policy violation while occur while updating packages due to unusual behavior such as restarting daemons. So, don't forget to monitor Window-1.

After you finished updating packages, wait for 10 seconds, then, terminate ld-watch with Ctrl-C that is running in Window-2.

Next, save current policy manually.

/root/ccstools/savepolicy a

Run the following command to get the list of nonexistent pathnames.

/root/ccstools/findtemp --all < /root/security/exception_policy.txt

Open /root/security/exception_policy.txt using text editor and remove "allow_read" lines for nonexistent shared libraries. Then, reload the exception policy using the following command.

/root/ccstools/loadpolicy ef

Run the following command to get the list of nonexistent pathnames.

/root/ccstools/findtemp --all < /root/security/domain_policy.txt

You need to be careful if a lot of pathnames appeared. The directory part of pathnames may have changed by updating packages.

For example, logwatch included in Fedora Core 4 changes the pathnames by updating. The logwatch included in Fedora Core 4's installation CD holds configuration files in /etc/log.d/ directory. But by updating, the location changes to /etc/logwatch/ directory and /etc/log.d/ directory is removed.

If the patterns of changes are obvious, you can edit /root/security/domain_policy.txt using text editor. Then, reload the domain policy using the following command.

/root/ccstools/loadpolicy df

Do a series of operations to confirm that programs that are protected by MAC can run properly. If some access permissions are missing, the messages will be printed to Window-1, so don't forget to monitor Window-1.

Save policy again after you finished operation check.

/root/ccstools/savepolicy a

Switch the system state back to "reject immediately if the policy violation occurs".

/root/ccstools/setlevel MAX_ENFORCE_GRACE=0

Finally, terminate ccs-queryd with Ctrl-C that is running in Window-1.

You have finished updating policies. Close all windows.

sflogo.php