Section 14.4. Testing and Analyzing the Policy


14.4. Testing and Analyzing the Policy

In the testing and policy analysis step, we verify that our policy module is functionally correct and meets our security goals.

14.4.1. Testing the Policy Module

Assuming that we were able to compile, install, and load our new policy, and that we successfully labeled the filesystem, we are ready to begin functional testing of the IRC daemon and policy module. We perform only basic functional tests in this step. More extensive testing should be performed before using this policy module in a production environment.

First, we verify that the system is in permissive mode and the daemon is stopped. Running in permissive mode allows the IRC daemon to function properly so that we can see all of the requested access that our policy module did not allow. (Recall that in permissive mode, access denials are audited but not enforced.) The commands to switch to permissive mode and stop the IRC daemon are as follows:

# setenforce 0 # /etc/init.d/ircd stop Stopping ircd:                                             [  OK  ]


Next, we need to use the seaudit utility from the setools package, which should be installed on FC4 systems (see Appendix D, "SELinux Commands and Utilities," for an overview of setools, the open source package which, among other tools, includes apol). With seaudit, open the audit log and turn on monitoring using the Toggle Monitor button, ensure the status is On on the status bar. (see Figure 14-1). We use seaudit to view the audit log to determine whether the IRC daemon requests additional access not allowed by our policy module. We can also view the log files using the tail utility with the command tail -f /var/log/audit/audit.log.

Figure 14-1. Seaudit displaying audit messages generated while testing the IRC daemon


After starting seaudit, we start the IRC daemon with the following command:

# setenforce 0 # /etc/init.d/ircd start Starting ircd: ircd: version hybrid-7.2.0 ircd: pid 9052 ircd: running in background mode from /usr/lib/ircd [  OK  ]


If everything is configured correctly, we should be able to display the IRC daemon process with the correct type using the ps command, as follows:

# ps axZ | grep ircd root:system_r:ircd_t             1519 ?        00:00:00 ircd


We see that the IRC daemon is running with the correct security context.

Next, we connect to the IRC daemon using an IRC client. For example, Figure 14-2 shows the xchat client successfully connecting to the IRC daemon.

Figure 14-2. Connecting to the IRC daemon using xchat


Tip

Make certain that the firewall settings for the test system allow IRC traffic if you are using an IRC client on a separate machine.


14.4.1.1. Evaluating Audit Messages and Allowing Additional Access

After exercising the IRC daemon with simple tests, such as joining and talking on a channel, we can examine the audit logs for denials related to our policy module. Figure 14-1 shows the relevant audit messages generated during our testing of the IRC daemon. These messages show the IRC daemon requesting five additional accesses, which we did not allow in our initial policy:

  • Read configuration files in /etc/ (etc_t).

  • Fork another process.

  • Read and write to pseudo terminals owned by the system administrator (sysadm_devpts_t).

  • Write access to the configuration file (ircd_conf_t).

We must consider each of the access requests to determine whether additional access should be added to our policy module. It is important to not allow additional access simply because the IRC daemon attempted the access. When evaluating audit messages, the goal is not to just add allow rules until the denial messages disappear. Instead, each requested access should be carefully considered and, if it conflicts with our security goals, not permitted if the application can continue to function properly.

For example, in the audit messages listed previously, we see that the IRC daemon attempts to access its configuration file (ircd_conf_t) for writing. Allowing this access violates our security goal to protect the configuration file. Also, allowing the daemon to read and write system administrators' pseudo terminals is unnecessary and opens a potential attack vector. The other access requests appear to be appropriate, so we add allow rules to permit the access. Instead of allowing write access to the configuration files and allowing read and write to pseudo terminals owned by the system administrator, however, we add dontaudit rules and test to determine whether the IRC daemon correctly functions without this access.

Tip

Audit messages with unexpected types may signal a labeling problem. For example, a denial message for sysadm_t accessing an IRC daemon related type might be a sign that the entrypoint (/usr/bin/ircd) is not labeled correctly (ircd_exec_t), preventing the domain transition.


14.4.1.2. Adding Additional Access in the Example Policy

The additional access is allowed in the example policy with the following new policy statements in the ircd.te file:

allow ircd_t self : process fork; allow ircd_t etc_t : file r_file_perms;


Audit messages related to the access that we are not permitting are suppressed with the following dontaudit rules:

dontaudit ircd_t ircd_conf_t : file write; dontaudit ircd_t sysadm_devpts_t : chr_file { getattr read write };


14.4.1.3. Adding Additional Access in the Reference Policy

To add the other additional accesses, we add the following policy statements in the ircd.te file:

allow ircd_t self : process fork; files_read_etc_files(ircd_t)


As before, audit messages related to the access that we are not permitting are suppressed with the following dontaudit rule and interface call:

dontaudit ircd_t ircd_conf_t : file write; userdom_dontaudit_use_sysadm_ptys(ircd_t)


14.4.1.4. Testing the Additional Access

After compiling, installing, and reloading the modified policy, we must test the IRC daemon again. This time we will test in enforcing mode. Enforcing mode can be set and the IRC daemon restarted using the following commands:

# setenforce 1 # /etc/init.d/ircd restart Stopping ircd:                                             [  OK  ] Starting ircd: ircd: version hybrid-7.2.0 ircd: pid 2075 ircd: running in background mode from /usr/lib/ircd        [  OK  ]


Performing the same functional tests shows that the IRC daemon functions correctly despite the denial of write access to the configuration file and read/write access to system administrators' pseudo-terminals. Additional testing is likely required, but otherwise we have demonstrated that our policy module is functionally correct.

14.4.2. Policy Analysis

The final step in developing our policy module is to perform policy analysis to verify that we met our security goals. Functional testing is not sufficient as our goal is to add security, not functions. After all, we had a functioning IRC daemon before creating our policy module. Policy analysis, particularly using automated tools such as apol, enables us to verify that we added security with our policy module.

For example, Figure 14-3 shows a search in apol for all access that ircd_t has to ircd_conf_t, including indirect access through attributes. This allows us to verify that the IRC daemon (ircd_t) does not have write access to its configuration files (ircd_conf_t).

Figure 14-3. An apol rules search showing no write access by ircd_t to ircd_conf_t





SELinux by Example(c) Using Security Enhanced Linux
SELinux by Example: Using Security Enhanced Linux
ISBN: 0131963694
EAN: 2147483647
Year: 2007
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net