These testcases test the SELinux Security Module.

A kernel with SELinux configured, and SELinux policy and userspace
tools installed, are required to build and run the SELinux testsuite. 
Also, /usr/sbin should be included in PATH to ensure SELinux utilities
such as getenforce are found. The test_selinux.sh script adds /usr/sbin
to the PATH. 

You must also have the line:
       expand-check = 0
in your /etc/selinux/semanage.conf file as the test policy will violate some 
of the neverallow rules in the base policy.  This line may already be present
depending on your distribution; if not, add it before running the test suite
and remove it when done.

There are two ways to run the SELinux testcases:
	1. testsuite - all testcases
	2. individual testcases

 
Run as a Testsuite
--------------------	
You must first do a top-level 'make' and 'make install' to build and
install the LTP test harness, libraries and tools.
From the top of your LTP directory, i.e. .../ltp-full-<version>,
execute the following,
	make
	make install (must be root)

Now build the SELinux testsuite. First compile the testcases and then 
install them. Do this by changing into the selinux-testsuite directory
(cd to $LTPROOT/testcases/kernel/security/selinux-testsuite/tests)
and from the command line execute the following,
	make 
	make install (must be root)

To run the testsuite, change to the top level directory within
the LTP tree (cd to $LTPROOT). From the top level directory cd 
to the testscripts directory and from the command line execute,
	./test_selinux.sh

This script builds the test policy in the selinux-testsuite/refpolicy
directory and runs the testsuite. After the testcases have completed, 
the test policy will be removed and the original policy will be 
restored. Thus, if the test_selinux.sh script is not allowed 
to complete, you may manually have to restore your system's 
original policy. This can be done by changing to the the 
selinux-testsuite/refpolicy directory and from the commandline,
issue a "make cleanup" to remove the test policy and restore the 
original policy.

Results of the test run can be found in the results directory,
which resides in the top-level LTP directory (cd to $LTPROOT/results).
Currently, 3 files should exist in the results directory after 
the selinux-testsuite has been run,
	selinux   
	selinux.logfile
	selinux.outfile

The 'selinux' file is known as the active-file.
It contains tags, pids, and commands being run.
The 'selinux.logfile' contains exit information for each testcase.
View this file if you want to know which SELinux testcases
passed or failed.
The 'selinux.outfile' contains all test output. View this file
if you want more detailed information about each testcase's execution.


Run Individual Testcases
--------------------------
First build the test policy manually. Do this by first changing 
to the selinux-testsuite refpolicy directory (cd to 
$LTPROOT/testcases/kernel/security/selinux-testsuite/refpolicy)
and build the policy by doing a, 
	make load

This will build and install the test policy files. Once the 
policy has been installed, individuall testcases can be run. 
To run an individual selinux testcase, change to the tests directory 
(cd to $LTPROOT/testcases/kernel/security/selinux-testsuite/tests)
and execute,
	runtest.sh <testcase>
	<testcase> - names one of the directories off of the
	selinux-testsuite/tests diretcory. For example, 
				runtest.sh capable_file
				runtest.sh capable_net
				runtest.sh entrypoint
				runtest.sh task_create

Most output, errors, and whether testcases have failed or succeeded 
will be sent to standard output for viewing.

To debug a test and get more detailed information,
a "set -x" can be added to the top of the *.sh file in the 
testcase directory of the testcase being debugged.	

To remove the test policy and restore original policy,
cd to selinux-testsuite/refpolicy directory and execute,
	make cleanup

Remember to remove test policy and restore original policy after
running/debugging individual testcases and it is desired to restore
system policy. None of the testscripts will do this for you when 
running in "individual" mode.

Your Kernel should have been built with the following options to
test SELinux:

CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_FILE_CAPABILITIES=y

CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
This has to be set to a positive value if you want to test this check.
Fedora kernels set it to 65536.

CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y

CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX=y
You don't want this one unless you are running Fedora 3 or 4.
On anything newer, it will cause unnecessary policy expansion.

CONFIG_SECURITY_SMACK=y
CONFIG_SECURITY_SELINUX=y

By default, if you boot with multiple LSMs compiled into the kernel, the
kernel won't boot succesfully - there can be only one (aside from
explicit internal "stacking" e.g. as is done for combining SELinux or
Smack with capabilities).  Unless you use the security= option to select
one at boot.  SELinux and Smack will honor the security= option.
