Document Control

Reviewers

This document is distributed by 7UGA 5R Linux OS – Maroon.

Change Summary

Overview

Purpose

The purpose of the Security Function Verification test is to demonstrate the correct operation of security functions identified in the SuSE Linux Enterprise Server V8 (SLES8) Security Target for EAL3. The term “correct operation” is defined to include appropriate failures for unauthorized or invalid access to security functions.

Scope

The test cases identified in this test plan are limited to those areas that enforce the secure operation of SLES8. Furthermore, only features and functions contained in the SLES8 Security Target for EAL3 are addressed. Test cases are designed to verify the correct operation of security related user programs, databases (files), and system calls. Testing for system availability in a stress environment is beyond the scope of this plan.

Environment

The following hardware and software will be used:

o The IBM xSeries Model x335 will be tested using both the k_deflt and the k_smp SLES8 kernels.

Assumptions and Dependencies

Assumptions

• The test cases will execute locally to the test target machine (i.e. not as a remote client).
• Multiple test suites are not running concurrently.
• The test cases have control of the execution environment. No other activity that changes system configuration can be performed simultaneously with the test cases.

Dependencies

• The file system must be mounted with user_xattr
• Completion of the eal3-certification rpm.
• Completion of the security guide.
• Availability of suitable hardware.

Test Approach and Methodology

Function Tests

• The test suite package includes the PAN testing framework.
• Where suitable, tests available from the Linux Test Project (LTP) have been utilized.
• Where possible, the test suite is designed to run automatically, without user intervention.
• Test cases are self contained and create/remove any resources required for validation (i.e. users, groups, files).
• Test case source code contains descriptions of the test objective, the method of verification, and the expected result.
• Test cases are self reporting. Each test case will check the actual result against the expected result and output a PASS/FAIL status.
• Test cases may be executed individually without requiring the entire test suite to run.
• Manual testing is performed only when automated options are not available.

LAuS Tests

• Successful and unsuccessful test cases exist for each security relevant syscall, except for a small number of syscalls where producing an unsuccessful test case was not feasible, for example, fork, exit, and brk. These tests will report a SKIPPED.
• The audit_tools tests create audit records for each record type: EXIT, LOGIN, SYSCALL, NETLINK, and TEXT. The aucat tests verify the record is found. The augrep tests verify the search options documented in the man page for each record type.
• The audbin test verifies man page options for the audbin utility.
• The fail-safe tests verify the proper behavior of the audit subsystem when bin mode log files are filled.
• The filter-conf tests verify the correct operation of filters contained in the filter.conf file, including filtering by login uid.
• The libpam tests verify that AUTH_success and AUTH_failure audit records are produced by libpam.
• The pam_laus tests verify audit records created by pam_laus.so.
• The trustedprogram tests verify audit records produced by executables that have been modified to use LAuS.
• The audit_trail_protection tests verify the access rights to sensitive audit related files.

• Tests for Triple DES, Diffie-Hellman, SHA-1, RC4, and RSA were obtained from the OpenSSL site.
• The random number generation test was also obtained from OpenSSL, but was enhanced to include some FIPS 140-1 testing.
• stunnel is used to verify network protocol functionality.
• The tests are designed to run against a reference implementation of SSL.
• Information such as hostname, user, password for the reference implementation must be defined in environment variables.
• Further documentation is available in the ltp_OpenSSL/testscases/openssl/READMEfile.

Internal Interfaces

• Execution of internal functions will be verified using kernels instrumented with gcov.
• The SLES 8, Service Pack 3 kernels will be patched and included with the test suite.
• All automated tests will be run using the patched kernel.
• The gcov output will generate html files to display the source lines of code executed within the kernel.
• The evaluator must use a browser to navigate through the gcov output to verify the internal functions were executed at least once during testing.

The following packages should be added through YaST2, including dependencies added automatically (verified through 'rpmqpack' output):

Note: The perl-Expect, perl-IO-Tty, and perl-IO-Stty rpms may be found on the Supplementary CDs for PPC and s390 platforms.

• attr-devel
• binutils
• cpp
• cross-ppc64-gcc for ppc64 platforms
• cross-ppc64-libs_and_headers for ppc64 platforms
• expect
• perl-Expect (for xSeries and eSeries see “Install perl expect for xSeries/eSeries”)
• perl-IO-Tty (for xSeries and eSeries see “Install perl expect for xSeries/eSeries”)
• perl-IO-Stty (for xSeries and eSeries see “Install perl expect for xSeries/eSeries”)
• flex
• gcc
• gcc-c++
• glibc-devel
• kernel-source (install from service pack)
• laus-devel (install from service pack)
• libstdc++-devel
• make
• openssl-devel
• tcl
• tk
• xshared

After installation of the kernel source, the following commands must be executed from the /usr/src/linux directory:

• make cloneconfig
• make dep

Install perl expect for xSeries and eSeries

For internet connected host

#Enter the following command:

perl -MCPAN -e shell

#Answer “no” to the following prompt::

Are you ready for manual configuration ? [yes] no

#At the cpan prompt run the “install Expect”n command:

cpan >install Expect

#Answer “yes” to the following prompt:

Shall I follow then and prepend to the queue of modules

we are processing right now? [yes] yes

#Quit the program

cpan >quit

For non-internet connected host

# Download the required files on an Internet-connected machine:

The additional packages required for the test environment are all permitted according to the Security Guide ("Reviewing the system configuration"). There are no configuration violations such as setuid/setgid binaries, daemons, startup scripts or other prohibited changes. After installation of the test environment, the system remains compliant with the TOE.

Although the gcov instrumented kernels are modified versions of the TOE, all automated tests will be re-run to verify behavior is identical to the TOE. The data produced by gcov will only be used to verify that internal interfaces have been covered by the EAL3 test suites.

NOTES

o For the LAuS tests, in order to verify the login uid in the audit records is set appropriately and is not simply an uninitialized value of 0, the tester should create a test user. Prior to executing the LAuS tests, login as the test user and su to root.

o Some tests may leave the machine in an inconsistent state and cause the cron or at tests to fail. To avoid these spurious cron/at failures, the test host must be rebooted before attempting to run the test suite again.

o All tests are assumed to be running as root user.

Installation of Testcases

• Execute initial ssh to localhost as root to establish authenticity of ‘ localhost’. (This only needs to be performed once per freshly installed machine).
• Retrieve linux_security_test_suite_EAL3.tar.gz from the “Extending LTP” IIOSB project to the target test machine.
• Extract files into a directory readable by all.

Running All Automated Testcases

The set of automated tests is comprised of 5 separate suites: at_test_EAL, ext3_ACLs_tests, laus_test, ltp_EAL2, ltp_OpenSSL. Instructions for running each individual suite are provided in the following sections. However, it is possible to run the entire set of tests from the test root directory by following the instructions below.

• cd to the test root directory
• Export “.” To PATH (i.e. export PATH=$PATH:.).
• Export the root password in the ROOT_PASSWORD environment variable.
• Run “make”
• Run “make run”

A summary run.log file will be created in the test root directory. More detailed output will be located in the test suite directory in the <suite_name>. run.log file.

LTP Compliant Testcases

• cd to ltp_EAL2 subdirectory
• Run “make” (or “make CC=/opt/cross/bin/powerpc64-linux-gcc” on ppc64 platforms).
• Run “make install”.
• Export “.” To PATH (i.e. export PATH=$PATH:.).
• Export the root password in the ROOT_PASSWORD environment variable.
• Run “./runalltests.sh –N –p –l <logfile>”
• View the test execution results in the results/<logfile> file.
• To execute a single test case, cd to ltp_EAL2/testcases/bin directory and run the desired test (for example ./chmod01). Test results will output to stdout.

• cd to at_test_EAL subdirectory.
• Run “sh runme.sh 2>&1 | tee <output file>”
• View execution results in <output file>.

ACL Testcases (standalone)

• cd to ext3_ACLS_tests subdirectory.
• Run “sh runme”
• View execution results in the ACL_TEST_RESULTS.log file.

OpenSSL Tests

• cd to ltp_OpenSSL/testcases/openssl
• Run “make”.
• Run “make install”.
• Run “install.sh”.
• Export environment variables defined in ltp_OpenSSL/testcases/openssl/environment_variables.txt
• Run “openssl01”.
• Test results will output to stdout.

LAuS Tests

• cd to laus_test
• Execute “make”.
• Execute “make run”.
• Test results are directed to log files with each test directory (audbin, audit_tools, audit_trail_protection, fail-safe, filter-conf, libpam, pam_laus, syscalls, trustedprograms).
• Execute “make report” to obtain a summary report.

Internal Interfaces

• Install the gcov kernel rpm (gcov/kernel-gcov-<platform>.rpm).
• On zSeries, you must run “ zipl” after installing the gcov kernel.
• Install the lcov rpm. (gcov/lcov-1.1-1.rpm).
• boot gcov instrumented kernel.
• Run “modprobe gcov-proc”
• (a) Run “lcov –z” (this will zero counters)
• (b) Run a test. The testname will be used in the lcov command in step (c).
• (c) Run “lcov –t <testname> -c –o <infofile.info>” where <testname> is the name of the testcase, and <infofile.info> is the pathname of the test info output file.
• Repeat steps a, b and c for each test specifying separate output files.
• Run “genhtml –s –t <title> -o <output_directory> <infofile.info> <infofile.info> … “
• View <output_directory>/index.html

Manual Tests

• See appendix B.

• System test will begin on upon availability of SLES 8, Service Pack 3 ISO images.

• At least 95% of the test cases must pass.
• No critical defects remain open.
• Tests executed on IBM xSeries – Model x335 on k_deflt kernel.
• Tests executed on IBM xSeries – Model x335 on k_smp kernel.
• Tests executed on IBM zSeries – Model z900.
• Tests executed on IBM iSeries – Model 825 machine type 9406.
• Tests executed on IBM pSeries – Model 630.
• Tests executed on IBM eServer 325.

Test Tools

• PAN – Test framework used by the Linux Test Project (LTP).
• expect / perl-Expect – A tool for automating interactive applications such as login, ssh, etc.

Security Function/Test Case Mapping

• See EAL3_testcase_mapping.xls spreadsheet.

Execution Plan

This is the tentative Execution Plan for SLES8 EAL3 security function verification. This portion of the plan will be updated with actual dates as the product is under test. This document will be the best source to determine in what state the product test is in. It is important to also list key milestones or checkpoints so others will be able to determine how the project is going.

Manual Tests

login (not valid for iSeries or zSeries)

o From the console, attempt to login as root with an invalid password (login should fail)

o Attempt to login with invalid (non-existing) username. (login should fail)

o Attempt to login as root with valid password. (login should succeed)

o Execute “id” command and verify identity (i.e. uid=0)

o Execute “faillog” command and verify invalid login attempts were recorded.

o Execute “lastlog” command and verify root user login date/time is correct.

o Verify libpam audit record for failed login attempt by executing “ augrep –e TEXT –U AUTH_failure”.

o [AUTH_failure] PAM authentication: user=<username> (hostname=<hostname>, addr=xx.xx.xx.xx, terminal=<terminal>)

o Verify libpam audit record for successful login attempt by executing “ augrep –e TEXT –U AUTH_success”.

o [AUTH_success] PAM authentication: user=<username> (hostname=<hostname>, addr=xx.xx.xx.xx, terminal=<terminal>)

o Verify pam_laus audit record for successful login attempt by executing “ augrep –e LOGIN”.

o [AUDIT_login] LOGIN: uid=<uid>, hostname=<hostname>, address=xx.xx.xx.xx, terminal=<terminal>, executable=<executable>

/etc/securetty, /sbin/agetty, (not valid for iSeries or zSeries)

o Connect serial terminal to target of evaluation.

o Add the following line to /etc/inittab

o S0:2345:respawn:/sbin/agetty –L 9600 ttyS0

o Reboot machine (optionally change init level or run “init q”h ).

o Verify “root” is denied login access from the serial terminal.

o Add “ttyS0” to the /etc/securetty file.

o Verify “root” is allowed login access from the serial terminal.

/etc/inittab & /sbin/init

o Add the following line to /etc/inittab

o TEAL:2345:respawn:/bin/sleep 300

o Reboot machine (optionally change init level or run “init q”h ).

o Verify the sleep process is running (ps – ef | grep “/bin/sleep 300”) .

o Remove line from /etc/inittab.

o Reboot machine (or change init level).

o Verify the sleep process is not running.

/sbin/mingetty (not valid for iSeries or zSeries)

o Open a virtual console using Cntrl-Alt-Fn, where n is 1-6.

o Attempt to login as root with an invalid password. The login operation should fail.

o Attempt to login as root with a valid operation. The login operation should be successful.

o Execute “w” command.

o Verify TTY is correct (i.e. ttyn).

o Verify USER is “root”.

o Verify LOGIN@ time is correct (i.e. current time).

mount

o cd to ltp_EAL2/testcases/bin subdirectory (for example /test_EAL2/ltp_EAL2/testcases/bin).

o Run “./mount01 –D /dev/...” (where /dev/… is an umounted block device)

o Run “./mount02 –D /dev/...”

o Run “./mount03 –D /dev/...”

o Run “./mount04 –D /dev/...”

Note: On zSeries, test case failures are expected due to differences in errno values. Tests 8 and 9 expect errno 14 (EFAULT) but receive errno 19 (ENODEV) and 22 (EINVAL) respectively. The difference in errno values does not pose any security problems.

amtu

o Run “amtu –m”.

o Run “amtu –s”.

o Run “amtu –i”.

o Run “amtu –n”.

o Run “amtu –p”.

o Run “augrep –e TEXT –X amtu”

o Verify an audit record exists for each amtu command.

/etc/init.d/audit

o Verify auditd or auditd64 is not running.

o Save /etc/audit/filter.conf.

o Run “echo ‘event user-message = always;’ > /etc/audit/filter.conf”

o Run “ /etc/init.d/audit start”.

o Run “augrep –e TEXT” and verify [AUDIT_start] record is created.

o Run “ /etc/init.d/audit status”.

o Verify “running” status is displayed

o Run “ /etc/init.d/audit restart”.

o Run “augrep –e TEXT” and verify [AUDIT_stop] and [AUDIT_start] records are created.

o Run “ /etc/init.d/audit try-restart”.

o Run “augrep –e TEXT” and verify [AUDIT_stop] and [AUDIT_start] records are created.

o Run “echo 2 > /proc/sys/dev/audit/debug”.

o Run “ /etc/init.d/audit reload”.

o Run “dmesg” and verify “auditf_read: called” is displayed.

o Run “ /etc/init.d/audit force-reload”.

o Run “dmesg” and verify “auditf_read: called” is displayed a second time.

o Run “echo 0 > /proc/sys/dev/audit/debug”.

o Run “ /etc/init.d/audit stop”.

o Run “augrep –e TEXT” and verify [AUDIT_stop] record is created.

o Restore original /etc/audit/filter.conf file.

aurun

o Remove reference to pam_laus.so from /etc/pam.d/sshd if it exists.

o ssh to test machine (the user will not be attached to LAuS).

o If not root, su to root.

o cd to laus_tests/audit_tools.

o If not already built, run “make”.

o Run “aurun make run”.

o All tests should report PASS which verifies aurun correctly attached to LAuS.

OpenSSL Interoperability Tests

• Create a self signed certificate for stunnel according to the instructions in the SLES Security Guide.
• Run

	stunnel
	-D7 -C RC4-SHA \

	-d 443 -g nogroup -s nobody \

	-l /bin/sh -- sh -c "

	dd
	bs=65536 count=1 >/dev/null 2>&1;

	echo 'HTTP/1.0 200 OK';

	echo 'Content-Type: text/html';

	echo;

	echo '<h1>Hello World</h1><pre>';

	free;

	echo '</pre>'

	"

xSeries

o PASSED: 1194

o FAILED: 2

o msgrcv 2 – SuSE bugzilla 32324 (aucat/augrep are not affected).

o SKIPPED: 20

o brk 4 – fail case N/A.

o exit 4 – fail case N/A.

o fork 4 – fail case N/A.

o umask 4 – fail case N/A.

o vfork 4 – fail case N/A.

pSeries

o PASSED: 926

o FAILED: 2

o close 2 – close audit record does not contain filename.

o SKIPPED: 24

o brk 4 – fail case N/A.

o exit 4 – fail case N/A.

o fork 4 – fail case N/A.

o umask 4 – fail case N/A.

o vfork 4 – fail case N/A.

o uselib 4 – success case N/A.

iSeries

o PASSED: 926

o FAILED: 2

o close 2 – close audit record does not contain filename.

o SKIPPED: 24

o brk 4 – fail case N/A.

o exit 4 – fail case N/A.

o fork 4 – fail case N/A.

o umask 4 – fail case N/A.

o vfork 4 – fail case N/A.

o uselib 4 – success case N/A.

zSeries

o PASSED: 1110

o FAILED: 54 (SuSE bugzilla tickets 30277, 32324)

o ftruncate 2 – SuSE bugzilla 30277 (sign extension)

o setregid 4 – SuSE bugzilla 30277 (sign extension)

o setregid16 4 – SuSE bugzilla 30277 (sign extension)

o setregid32 4 – SuSE bugzilla 30277 (sign extension)

o setresgid 4 – SuSE bugzilla 30277 (sign extension)

o setresgid16 4 – SuSE bugzilla 30277 (sign extension)

o setresgid32 4 – SuSE bugzilla 30277 (sign extension)

o setresuid 4 – SuSE bugzilla 30277 (sign extension)

o setresuid16 4 – SuSE bugzilla 30277 (sign extension)

o setresuid32 4 – SuSE bugzilla 30277 (sign extension)

o setreuid 4 – SuSE bugzilla 30277 (sign extension)

o setreuid16 4 – SuSE bugzilla 30277 (sign extension)

o setreuid32 4 – SuSE bugzilla 30277 (sign extension)

o truncate 2 – SuSE bugzilla 30277 (sign extension)

o msgrcv 2 – SuSE bugzilla 32324 (aucat/augrep are not affected).

o

o SKIPPED: 28

o brk 4 – fail case N/A.

o clone 4 – CLONE_PID has known issues. No other easy way to cause a failure.

o exit 4 – fail case N/A.

o fork 4 – fail case N/A.

o umask 4 – fail case N/A.

o vfork 4 – fail case N/A.

o uselib 4 – success case N/A.

eServer 325

o PASSED: 886

o FAILED: 18

o setregid 4 – SuSE bugzilla 31058 (sign extension)

o setresgid 4 – SuSE bugzilla 31058 (sign extension)

o setresuid 4 – SuSE bugzilla 31058 (sign extension)

o setreuid 4 – SuSE bugzilla 31058 (sign extension)

o msgrcv 2 – SuSE bugzilla 32324 (aucat/augrep are not affected).

o

o SKIPPED: 24

o brk 4 – fail case N/A.

o exit 4 – fail case N/A.

o fork 4 – fail case N/A.

o umask 4 – fail case N/A.

o vfork 4 – fail case N/A.

o uselib 4 – success case N/A.

Other Known Failures

login (manual test) – The faillog portion of the login test does not work as described. Failed login attempts are recorded by the audit subsystem.

mount02 (manual test) – On zSeries, test case failures are expected due to differences in errno values. Tests 8 and 9 expect errno 14 (EFAULT) but receive errno 19 (ENODEV) and 22 (EINVAL) respectively. The difference in errno values does not pose any security problems.

OpenSSL Interoperability Test – The test using the TDES cipher with OpenSSL is expected to fail due to interoperability problems.

End of Document

Owner: Daniel H. Jones