This directory contains the functional test suite for the LSM-based SELinux security module. Please refer to the test report available in doc/tests for complete documentation for this test suite. This README only covers a subset of that report, specifically the sections on running the tests and adding new tests.
Your kernel should have been built with the following options to test SELinux:
CONFIG_AUDIT=y CONFIG_NET=y CONFIG_INET=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_SELINUX=y
CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS_SECURITY=y CONFIG_JFS_SECURITY=y CONFIG_XFS_SECURITY=y CONFIG_JFFS2_FS_SECURITY=y
The following config options are not required by the tests but are typical settings for SELinux kernel configuration: CONFIG_SECURITY_NETWORK_XFRM=y CONFIG_NETLABEL=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y CONFIG_SECURITY_SELINUX_AVC_STATS=y
Do not set CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX; it is an option for legacy distributions (Fedora 3 and 4).
The capabilities module and the file capability support may be enabled simultaneously with SELinux with no conflicts if you wish to also exercise their ltp tests: CONFIG_SECURITY_CAPABILITIES=y # Removed in 2.6.27 and later. CONFIG_SECURITY_FILE_CAPABILITIES=y
Otherwise, you should not enable any other security modules in your kernel configuration unless you use the security= option to select a module at boot time. Only one primary security module may be active at a time.
The testsuite requires a pre-existing base policy configuration of SELinux, using either the old example policy or the reference policy as the baseline. It also requires the core SELinux userland packages (libsepol, checkpolicy, libselinux, policycoreutils, and if using modular policy, libsemanage) to be installed. The test scripts also rely upon the SELinux extensions being integrated into the coreutils package, with support for the chcon and runcon commands as well as the SELinux options to existing utilities such as ls and mkdir.
In addition to the libselinux shared library, the libselinux headers are required in order to build certain testcases. These can be found in the libselinux-devel package in Fedora or RHEL.
On systems whose policy was derived from the old example policy (e.g. RHEL 4), the base policy sources must be installed on the system, e.g. the selinux-policy-targeted-sources package in RHEL 4.
On systems whose policy is derived from the reference policy (e.g. RHEL 5, Fedora 5 or later), the policy module development files (Makefile and include tree) must be installed on the system, e.g. the selinux-policy-devel package in RHEL 5, subsequently folded into the base selinux-policy package in Fedora 10 and later.
If the base distribution does not include the SELinux userland, then the source code for the core SELinux userland packages can be obtained from: http://userspace.selinuxproject.org
If the base distribution does not include a policy configuration, then the reference policy can be obtained from: http://oss.tresys.com/projects/refpolicy
Create a shell with the unconfined_r or sysadm_r role and the Linux superuser identity, e.g.: newrole -r sysadm_r # -strict or -mls policy only su
Check whether the SELinux kernel is in enforcing mode by running 'getenforce'. If it is in permissive mode, toggle it into enforcing mode by running 'setenforce 1'.
To run the test suite, you can just do a 'make test' from the top-level directory or you can follow these broken-out steps:
1) Load the test policy configuration as follows: make -C policy load
2) Build and run the test suite from the tests subdirectory as follows: make -C tests test
3) Unload the test policy configuration as follows: make -C policy unload
The broken-out steps allow you to run the tests multiple times without loading policy each time.
4) Review the test results.
As each test script is run, the name of the script will be displayed followed by a status. After running all of the test scripts, a summary of the test results will be displayed. If all tests were successful, something similar to the following summary will be displayed (the specific numbers will vary):
All tests successful. Files=7, Tests=16, 2 wallclock secs ( 0.17 cusr + 0.12 csys = 0.29 CPU)
Otherwise, if one or more tests failed, the script will report statistics on the number of tests that succeeded and will include a table summarizing which tests had failed. The output will be similar to the following text, which shows that a total of three tests have failed:
entrypoint/test 2 1 50.00% 1 inherit/test 3 2 66.67% 1-2 Failed 2/7 test scripts, 71.43% okay. 3/16 subtests failed, 81.25% okay. make: *** [test] Error 255
You can also run individual test scripts by hand, e.g. running ./entrypoint/test, to see the raw output of the test script. This is particularly useful if a particular test within a given script fails in order to help identify the cause. When run by hand, the test script displays the expected number of tests, a status for each test, and any error messages from the test script or its helper programs.
Please report any failures to the selinux@tycho.nsa.gov mailing list, including a copy of the test summary output, the raw output from test scripts that failed, a description of your base platform, and the particular release of SELinux that you are using.
The functional test suite is not yet complete, so we still need additional tests to be written. See the test report for the current coverage.
To add a new test, create a new test policy file and a new test script. The new test policy file should be added to the policy directory and should contain a set of test domains and types specifically designed for the test. For the test script, create a new subdirectory in the tests subdirectory, populate it with at least a Makefile and a test perl script and add it to the SUBDIRS definition in the Makefile file.
The Makefile must contain 'all' and 'clean' targets, even if they are empty, to support the build system. The test script must run with no arguments and must comply with the perl automated test format. The simplest way to comply with the Perl automated test format is to use the Perl Test module. To do this, first include the following statement at the top of the test Perl script: use Test;
Next, include a declaration that specifies how many tests the script will run; the statement to include will be similar to: BEGIN { plan tests => 2} # run two tests
You can then use the 'ok' subroutine to print results ok(1); # success ok(0); # failure ok(0,1); # failure, got '0', expected '1' ok($results, 0); # success if $results == 0, failure otherwise
Standard error is ignored.
In general, the scripts need to know where they are located so that they can avoid hard-coded paths. Use the following line of Perl to establish a base directory (based on the path of the script executable). This won't always be accurate, but will work for this test harness/configuration. $basedir = $0; $basedir =~ s|(.)/[^/]|$1|;