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 (the test_selinux.sh script does this automatically).

A test policy module is added to the base policy during the execution
of the test cases and then removed.  The test policy sources for
systems using the SELinux reference policy (e.g. Fedora 5 and later,
RHEL 5 and later) are located under the selinux-testsuite/refpolicy
directory, while the test policy sources for systems using the older
SELinux example policy (e.g. RHEL 4) are located in the
selinux-testsuite/policy directory.  All further references to the
test policy directory in this README will use the $POLICYDIR notation
to refer to whichever test policy is appropriate for the system.  The
test_selinux.sh script sets POLICYDIR to one of these locations.

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 $POLICYDIR 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 $POLICYDIR 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 $POLICYDIR directory and build the policy by doing:
	make load

This will build and install the test policy files. Once the 
policy has been installed, individual 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, run:
        cd $POLICYDIR && 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.


Kernel Configuration
--------------------

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

# Minimal dependencies.
CONFIG_AUDIT=y
CONFIG_NET=y
CONFIG_INET=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y

# Filesystem security labeling support.
# Only need to enable the ones for the filesystems on which you are testing.
# reiserfs is not supported.
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.


SELinux Policy and Userland
---------------------------

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
and the libselinux static library are required in order to build
certain testcases.  These can be found in the libselinux-devel and
libselinux-static packages respectively in modern Fedora releases, or
in the libselinux-devel package in RHEL 5.

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.
The test policy will look in $SELINUX_SRC as defined in
selinux-testsuite/policy/Makefile for the base policy sources.

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.  The test policy
will look in $POLICYDEVEL as defined in
selinux-testsuite/refpolicy/Makefile for the policy module development
files.

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
