Test Plan

for

SUSE Linux Enterprise Server V9

EAL4 Security Function Verification

 


 

Version: 1.3

Owner: Kimberly D. Simon

kdsimon@us.ibm.com

IBM Linux Technology Center – Security

11501 Burnet Road

Austin, TX 78758

 



It is the responsibility of the user of this document to ensure that they are using the current version of this document. To validate that your copy of this document is at the latest level, view the latest version of this document from the IBM Internal Open Source Bazaar (IIOSB) “Extending LTP” project (under /documents/EAL4).  


Table of Contents

ź         3.3.1 Software/Hardware

ź         6.1.1 Automated Configuration

ź         6.1.2 Manual Configuration

ź         8.9.1 Memory

ź         8.9.2 Memory Separation

ź         8.9.3 I/O Controller - Network

ź         8.9.4 I/O Controller - Disk

ź         8.9.5 Supervisor Mode Instructions

ź         10.3.1 laus_test

o        10.3.1.1 audbin

o        10.3.1.2 audit_tools

o        10.3.1.3 audit_trail_protection

o        10.3.1.4 fail-safe

o        10.3.1.5 filter-conf

o        10.3.1.6 libpam

o        10.3.1.7 pam_laus

o        10.3.1.8 syscalls

o        10.3.1.9 trustedprograms

ź         10.3.2 misc_test

o        10.3.2.1 OpenSSL

o        10.3.2.2 at_crontab

o        10.3.2.3 databases

o        10.3.2.4 eal

o        10.3.2.5 ext3_acls

o        10.3.2.6 gcov

o        10.3.2.7 object_reuse

o        10.3.2.8 permission

o        10.3.2.9 proc_sys_perms

ź         10.3.3 LTP

ź         10.3.4 Manual Tests


Chapter 1. LEGAL NOTICES

The following terms are registered trademarks of International Business Machines Corporation in the United States and/or other countries: IBM, eServer, xSeries, pSeries, DB2, WebSphere. A full list of U.S. trademarks owned by IBM may be found at http://www.ibm.com/legal/copytrade.shtmal.

Linux is a registered trademark of Linus Torvalds.

Other company, product, and service names may be trademarks or service marks of others.


Chapter 2. Document Control


2.1 Reviewers

Name

Organization

Daniel Jones

7UGA 7T LTC Security – Maroon

Loulwa Salem

7UGA 7T LTC Security – Maroon

Paul Edgar

8B5A 7T LTC Test

Stephan Mueller

@sec information security GmbH

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


2.2 Change Summary

Date

Version

Description of Changes

06/04/2004

Draft 0.1

Initial Draft

07/01/2004

Draft 0.2

Continued development:

Reformatted document table of contents and sections.

Removed reference to eclipse website.

Updated all references to EAL3 and SLES8.

Updated Assumptions/Dependencies section.

Updated packages to Installation of Test Environment section.

Renamed Running All Automated Testcases section.

Added mode information for Running All Automated Testcases section.

Added caveat to LAuS Tests section.

Updated Appendix B for /etc/init.d/audit, mount, /etc/securetty, and OpenSSL Interoperability Tests sections.

Updated the LTP Compliant Testcases section.

Revise Test Execution section to include miscellaneous tests (misc_test).

Added section for autoinstallation script.

Note: All items to be updated have been temporarily highlighted in red.

8/31/2004

Draft 0.3

Updates per reviews by Dan Jones and Loulwa Salem:

Changed references to SuSE to SUSE.

Changed references to SLES9 to SLES 9.

Changed document owner.

Updated list of reviewers.

Removed change summary pertaining to EAL3 Test Plan.

Changed reference to Security Target in Purpose section.

Updated hardware models in Environment and System Exit Test Criteria sections.

Removed auto installation script section.

Removed Install Perl Expect section.

Updated test listing for LTP Tests section.

Removed exit from laus_test section.

Removed audit from heading for misc_test section.

Updated OpenSSL tests under misc_test section to refer to execution against localhost.

Removed requirement for misc_test to be executed in 32-bit and 64-bit modes.

Added descriptions for databases, eal, and object_reuse.

Removed au_login section and references.

Updated System Test Entry Criteria section.

Updated commands in 10.1 Notes section.

Updated family for Problem Reporting and Tracking section.

Updated package list for Manual Configuration section.

Updated “ttySO” typo in section 8.5.

Added step to restart audit for /etc/init.d/audit section under Manual Tests in Appendix B.

Correct path for mount section under Manual Test in Appendix B.

Added fchmod06 to Other Known Failures section.

Updated steps in section 10.3.1.

Removed statfs03 from LTP tests – Automated section.

Updated steps for Executing Automated Tests Individually section.

Added pointer to instructions for Manual Tests section.

Updated document location for Security Function/Testcase Mapping section.

Fix links for Table of Contents section.

Updated Assumptions section.

Removed failure caveat in login section of Appendix B.

Removed tk and tk-devel packages from Manual Configuration section.

Removed faillog from Appendix C.

9/28/2004

Draft 0.4

Removed 64-mode requirement under misc_test section.

Removed mount02 from Appendix C.

Added sendmsg01 to Appendix C.

Removed “make install” step from section 10.3.3.

Updated list of reviewers in section 2.1.

Added semctl32 to Appendix C.

Added bugzilla ticket numbers to Appendix C.

Removed OpenSSL Interoperability Test from Appendix C.

Updated OpenSSL Interoperability Test in Appendix B.

Added laus-devel packages to section 6.1.2.

Modifed 10.1 Notes section to include steps for limiting growth of audit files.

Removed Note for Perl packages under section 6.1.2.

Updated local_enable flag under 10.1 Notes section.

Removed fchmod06 from Appendix C.

Added AES128 and AES256 to OpenSSL Interoperability Tests in Appendix B.

Removed Note for expected failure under OpenSSL Interoperability Tests in Appendix B.

Modified 32-bit mode instructions for Executing Automated Testcases Individually in section 10.3.

Removed minicom from section 6.1.2.

Added proc_sys_perms test to misc_test section 10.3.2.9.

Updated misc_test heading for section 8.2.

Added proc_sys_perms description in section 8.2.

Added proc_sys_perms expected failure in Appendix C.

Removed semctl32 known failure in Appendix C.

Added eServer 325 to be tested with both default and smp kernels in section 3.3.1.

Added openssl-devel-64bit package in section 6.1.2.

10/13/2004

Draft 0.5

Added 32-bit packages in section 6.1.2.

Removed nftw6401 from LTP tests section 8.3.

Modified LAuS Syscall Expected Results in Appendix C.

Added note to sections 6.1.1 and 10.1 about installing kernel-source.

Added Netscape 7.2 requirement for OpenSSL Interoperability manual tests.

Changed all references to SLES 9 security guide to configuration guide.

Updated name of gcov RPM in section 10.3.2.6.

Removed note under for mount section under Appendix B.

Added mount commands for nfs to Notes section 10.1.

Updated Appendix B to include make clean steps.

Updated expected failures errno 2 and 22 for proc_sys_perms section in Appendix B and Other

Known Failures section in Appendix C.

Updated OpenSSL Interoperability tests for /tmp/openssltest.conf in Appendix B.

10/20/2004

1.0

Updated gcov instructions in section 10.3.2.6.

Added note about executing gcov in section 10.1.

Added mount02 expected failure for zSeries in Appendix B and Appendix C.

Updated /etc/securetty section in Appendix B.

Update login section under Appendix B.

Updated dates for Execution Plan under Appendix A.

10/25/2004

1.1

Update per review by Stephan:

Removed listing of LTP tests for section 8.3

11/16/2004

1.2

Added comments regarding stime01 failure when compiled 31 bit on s390x.

11/19/2004

1.3

Add instruction for verification of tmpfs file system.


Chapter 3. Overview


3.1 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 V9 (SLES 9) Functional Specification for EAL4. The term “correct operation” is defined to include appropriate failures for unauthorized or invalid access to security functions.


3.2 Scope

The test cases identified in this test plan are limited to those areas that enforce the secure operation of SLES 9. Furthermore, only features and functions contained in the SLES 9 Security Target for EAL4 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.


3.3 Environment

3.3.1 Software/Hardware

The list of required packages, as well as configuration details will be provided by the EAL4 evaluation configuration guide. The setup of the test machine(s) must conform strictly with the instructions and configuration details described in this test plan and the EAL4 Evaluation Configuration Guide /usr/share/doc/packages/certification-sles-eal4/SLES-configuration-guide{txt|html|pdf|man}.  Additional software is listed in the “Installation of Test Environment” section of this document.

The following hardware will be used:

Hardware

Linux Distros

Version

IBM xSeries – Model x335

SUSE Linux Enterprise Server

V9

IBM zSeries – Model z990

SUSE Linux Enterprise Server

V9

IBM eServer i5 520

SUSE Linux Enterprise Server

V9

IBM eServer p5 520

SUSE Linux Enterprise Server

V9

IBM eServer 325

SUSE Linux Enterprise Server

V9

Serial Terminal (or PC with Terminal Emulation)

N/A

N/A

 

o       The IBM xSeries Model x335 and eServer 325 will be tested using both the k_deflt and the k_smp SLES 9 kernels.

o       The zSeries and eServer i5 520 systems will be configured within a logical partition (zSeries - z/VM, iSeries - DLPAR). 


Chapter 4. Assumptions and Dependencies


4.1 Assumptions

o        The test cases will execute locally to the test target machine (i.e. on the machine being tested, not as a remote client).

o        Multiple test suites are not running concurrently.

o        The test cases have control of the execution environment. No other activity that changes system configuration can be performed simultaneously with the test cases.


4.2. Dependencies

o        The file system must be mounted with acl, user_xattr.

o        Completion of the eal4-certification rpm.

o        Completion of the SLES 9 EAL4 configuration guide.

o        Availability of suitable hardware.

o        Availability of all software described in the Target of Evaluation (TOE), especially the audit subsystem.

o        Availability of the Abstract Machine Test Utility (AMTU) ported to SLES 9 for all platforms.

o        Availability of sufficient test personnel.


Chapter 5. Test Approach and Methodology


5.1 Function Tests

o        The test suite package includes the PAN testing framework.

o        Where suitable, tests available from the Linux Test Project (LTP) will be utilized.

o        Where possible, the test suite is designed to run automatically, without user intervention.

o        Test cases are self contained and create/remove any resources required for validation (i.e. users, groups, files).

o        Test case source code contains descriptions of the test objective, the method of verification, and the expected result.

o        Test cases are self-reporting. Each test case will check the actual result against the expected result and output a PASS/FAIL status.

o        Test cases may be executed individually without requiring the entire test suite to run.

o        Manual testing is performed only when automated options are not available.

o        Test cases will be stored in CVS under exltp project of the IIOSB.


Chapter 6. Installation of test environment


6.1 SUSE SLES Installation

Follow the instructions in the EAL4 Evaluation Configuration Guide for SUSE SLES 9.  Start with “Introduction” and continue up to the “Setting up Login Controls” section. For the “Selection of install options and packages” section, use the username “ealuser”.  Note that you can complete an automated or manual configuration.

6.1.1 Automated Configuration

Follow the steps in the “Automated configuration of the system” section of the EAL4 Evaluation Configuration Guide, which explains how to install the eal4-certification-doc RPM on a system.  Note: Be sure to manually install the appropriate kernel-source package before proceeding with Chapter10.  The certification RPM will not install kernel-source.

6.1.2 Manual Configuration

To manually configure a system, proceed with the “Add and remove packages” section of the EAL4 configuration guide.  In addition, the following software packages below should be added through YaST2 for test case support, including dependencies added automatically (verified through 'rpmqpack' output).

o        libattr-devel

o        binutils

o        cpp

o        cvs

o        expect

o        perl-Expect

o        perl-IO-Tty

o        perl-IO-Stty

o        flex

o        gcc

o        gcc-c++

o        gcc-64bit (for PPC)

o        glibc-devel

o        glibc-devel-32bit

o        glibc-devel-64bit (for PPC)

o        kernel-source

o        laus-64bit (for PPC)

o        laus-devel

o        laus-devel-32bit

o        laus-devel-64bit (for PPC)

o        libstdc++-devel

o        make

o        ncurses-devel

o        openssl-devel

o        openssl-devel-32bit

o        openssl-devel-64bit (for PPC)

o        patch

o        pam-laus-devel

o        tcl

o        tcl-devel


Chapter 7. Target of Evaluation (TOE) Compliance

The additional packages required for the test environment are all permitted according to the Configuration 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 EAL4 test suites.


Chapter 8. Testcase Descriptions

This section provides brief, high-level descriptions of the automated and manual testcases used for EAL4 verification test.


8.1 laus_test (Audit) - Automated

o        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, and brk. These tests will report a SKIPPED.

o        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.

o        The audbin test verifies man page options for the audbin utility.

o        The fail-safe tests verify the proper behavior of the audit subsystem when bin mode log files are filled.

o        The filter-conf tests verify the correct operation of filters contained in the filter.conf file, including filtering by login uid.

o        The libpam tests verify that AUTH_success and AUTH_failure audit records are produced by libpam.

o        The pam_laus tests verify audit records created by pam_laus.so.

o        The trustedprogram tests verify audit records produced by executables that have been modified to use LAuS.

o        The audit_trail_protection tests verify the access rights to sensitive audit related files.

o        On 64 bit systems, only syscalls must be compiled and executed using 32 bit and 64 bit (2 passes per 64 bit platform).

Note: the audit_tools/au_netlink and the filter-conf netlink tests assume the presence of an Ethernet device configured as eth0. If this device does not exist on the target of evaluation, these test will report failures.


8.2 misc_test – Automated with manual verification

This bucket consists of the following miscellaneous tests for EAL4 verification.  These tests are not required to be executed in 32-bit mode on 64-bit platforms.

o       OpenSSL

ź         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.  However, the tests will run against the localhost for the EAL4 evaluation.

ź         Information such as hostname, user, password for the reference implementation must be defined in environment variables.

ź         Further documentation is available in the /misc_test/OpenSSL/README file and in the “Test Execution” section of this document.

o       at_crontab

ź         These scripts test the basic functionality of the "at" and "cron" utilities which are used to schedule jobs at particular times in the future.

o       databases

ź         This suite verifies the correct operation of TSF databases.

o       eal

ź         These tests primarily ensure access permissions to TSF databases.  Also included is an ssh test to verify that the system will not permit root login.

o       ext3_acls

ź         These are the extended attribute/access control list tests.

o       gcov (Internal Interfaces)

ź         Execution of internal functions will be verified using kernels instrumented with gcov.

ź         The SLES 9 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.

o       object_reuse

ź         These tests verify the requirement that file system and IPC objects will be cleared before they are reallocated to a different user.

o       permission

ź         These are the tests for file access permissions.

o       proc_sys_perms

ź         These are the tests for file access permissions for the /proc filesystem.


8.3 LTP tests - Automated

This test bucket pertains to the subset below of the LTP test suite (no audit) for EAL4 verification.  On 64 bit systems, the LTP suite must be compiled and executed using 32 bit and 64 bit (2 passes per 64 bit platform).  For more information on LTP, visit http://ltp.sourgeforge.net.  For a listing of LTP tests, see the SLES 9 EAL4 Functional Specification in the EAL Documentation Project (ealdoc) located in IIOSB. 


8.4 login - Manual

These tests produce success and error cases for Login and verify proper audit records were created.


8.5 /etc/securetty, /etc/agetty - Manual

This test involves adding an agetty line to inittab and verifies root is denied access from a serial terminal until "ttyS0" is added to the /etc/securetty file.


8.6 /etc/inittab, /sbin/init - Manual

This adds sleep 300 to /etc/inittab and confirms sleep runs on reboot and does not run when the sleep is removed and the machine rebooted.


8.7 /etc/mingetty - Manual

This verifies success and error cases for login as root using /sbin/mingetty with a virtual console.


8.8 mount - Manual

This verifies success and error cases for the mount command.


8.9 amtu – Automated with manual verification

The Abstract Machine Test Utility (AMTU) is to be run to verify the hardware for all platforms and will be included in the certification rpm.

AMTU is an administrative utility to check whether the underlying protection mechanisms of the hardware are still being enforced. This is a requirement of the Controlled Access Protection Profile (CAPP) FTP_AMT.1, see http://www.radium.ncsc.mil/tpep/library/protection_profiles/CAPP-1.d.pdf. AMTU executes the following tests:

8.9.1 Memory

Randomly writes to areas of memory and then reading the memory back to ensure the values written remain unchanged.

8.9.2 Memory Separation

Ensures that user space programs cannot read and writes to areas of memory utilized by the likes of Video RAM, kernel code, etc.

8.9.3 I/O Controller - Network

Verifies random data transmitted is also the data received for each configured network device. Only ethernet and token ring devices that are configured and up are checked. Async devices are not checked.

8.9.4 I/O Controller - Disk

Verifies information written to disks remains unchanged. Only SCSI and IDE controllers associated with mounted filesystems are checked.

8.9.5 Supervisor Mode Instructions

Ensures the enforcement of the property that privileged instructions should only be in supervisor mode is still in effect. The set privileged instructions tested to confirm this is architecture dependent.


Chapter 9. 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).  Then ssh to the host as the test user, ealuser:

ssh –l ealuser <hostname> 
(Answer "Yes" to, "Are you sure you want to continue connecting?" and enter the password when requested.)

Use one of the two methods listed below to install the test files.  Note: The /tmp directory is shown in these examples, but you can choose another directory accessible by all users.

Method #1: Downloading test files using cvs command (use this OR Method #2 below).

To download the whole test bucket and auto install to a Linux system which has cvs installed:

   mkdir /tmp
   cd /tmp
   export CVS_RSH=ssh
   cvs –z9 –d:ext:yourid@cvs.opensource.ibm.com:/cvsroot/exltp co .
        (Note:  be sure to use the dot at the end.)
 
         OR - For anonymous access (read authority only):
 
   cvs -z9 -d:pserver:anonymous@cvs.opensource.ibm.com:/cvsroot/exltp co .
   (Note:  be sure to use the dot at the end.)

To only download a certain test, use the test name instead of "." in the command above.

Method #2: Installing all tests from the .tar.gz file

When it is available, retrieve linux_security_test_suite_EAL4.tar.gz from the exltp IIOSB project to the target test machine.  To download, follow steps in Method #1,  replacing the “.” with “linux_security_test_suite_EAL4.tar.gz” in the cvs command.  Then complete the following:

Extract the files into a directory readable by all, such as /tmp.

gunzip linux_security_test_suite_EAL4.tar.gz

tar -xvf linux_security_test_suite_EAL4.tar


Chapter 10. Test Execution


10.1 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 (see section “Select install options and packages” in the EAL4 configuration guide for adding a new user).  Prior to executing the LAuS tests, make sure you login as the test user (i.e. ealuser) and su to root (i.e. “/bin/su –“).

o       Testing requires a specific system configuration.  You MUST set up each system undergoing test according to this test plan and the EAL4 configuration guide BEFORE you begin any testing.

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       Please note that the audit files will grow indefinitely if you have the following in /etc/audit/audit.conf:

     notify="/usr/sbin/audbin -S /var/log/audit.d/save.%u -C"

 

One solution is to remove “-S <FILE>” in the notify command.  Be sure to leave “-C”.  Another solution is to replace the notify command in /etc/audit/audit.conf with:

     /bin/true

Also, be sure to set “sync = no” in the audit.conf.  The tests and test results may take up to 1 Gig. If you are using /tmp in a separate partition, make sure it has enough space.

o        Be sure to export “.” To PATH (i.e. export PATH=$PATH:.).

o        Be sure to export the root password in the PASSWD environment variable.

o        Be sure to export “localhost” to the RHOST environment variable (i.e. export RHOST=localhost).

o        Be sure to set “local_enable=YES” in the /etc/vsftpd.conf file.

o        Be sure to start vsftpd.  Do the following:

     chkconfig vsfptd on

     /etc/init.d/xinetd restart

o        The tests may leave the audit configuration files in an unstable state.  Be sure to save original copies of the audit configuration files, /etc/audit/audit.conf  (i.e. /etc/audit/audit.conf.original) and /etc/audit/filter.conf (i.e. /etc/audit/filter.conf.original).  If the audit configuration files become unstable, complete the following to restore the files:

         /etc/init.d/audit stop

     rm –rf /var/log/audit*

         cp /etc/audit/audit.conf.original /etc/audit/audit.conf

     cp /etc/audit/filter.conf.original /etc/audit/filter.conf.original

     /etc/init.d/audit start

o        Tests can be executed in 2 modes on a 64-bit platform: 32-bit (31-bit on zSeries) or 64-bit.  On a 64-bit platform, note that only LTP and syscalls (see section 10.3) must be executed in both 64-bit and 32-bit modes to satisfy EAL4 requirements.

o        Be sure to install the appropriate kernel-source package before building the tests in section 10.2.

o        After running the EAL4 certification RPM (see section 6.1.1), you will need to use one of the methods below to mount NFS shares:

          Add the “-o nolock” option when mounting NFS shares:   

mount -o nolock nfsserver:/export /local_mount_ point

                            OR

    In case you have the NFS share listed in /etc/fstab, you can put “nolock” in the Options column: 

skyline.ltc.austin.ibm.com:/public /mnt/skypub nfs noauto,nolock,rsize=4096,soft,intr 0 0

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


10.2 Building and Executing All Automated Testcases

The set of automated tests is comprised of 3 separate suites: LTP, laus_test, and misc_test.  However, it is possible to run the entire set of tests from the test root directory in the following sections below.  The tests can be executed in 2 modes on a 64-bit platform: 32-bit (31-bit on zSeries) or 64-bit.  The automated testcases may be executed individually as described in the following sections.  Note that the gcov tests are not executed as described in this section.  You must follow the instructions listed in section 10.3.2.6 to execute the gcov tests.

o        Make sure you have completed the steps listed in section10.1 Notes.

o        cd to the test root directory

o        Run “make MODE=64” to build the tests in 64-bit mode.  To build the tests in 32-bit mode (31-bit on zSeries), run “make MODE=32”.

o        Run “make MODE=64 run” to execute the tests in 64-bit mode.  To run the tests in 32-bit mode (31-bit on zSeries), run “make MODE=32 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 (example, ltp.run.log).  


10.3 Executing Automated Testcases Individually

Instructions for running each individual suite are provided in the following sections.  Note that only LTP and syscalls must be executed in both 32-bit and 64-bit modes on 64-bit platforms.  The instructions assume you have built the testcases from the top level directory as described in section 10.2.

10.3.1 laus_test

o        cd to laus_test directory.

o        On a 64-bit platform, run “make MODE=64 run” to execute the tests in 64-bit mode.  To run the tests in 32-bit mode (31-bit on zSeries), run “make MODE=32 run”.

o        Test results are directed to log files within each test directory (audbin, audit_tools, audit_trail_protection, fail-safe, filter-conf, libpam, pam_laus, syscalls, trustedprograms).

o        A summary report “run.log” will be created in the current directory.

10.3.1.1 audbin

o        cd to audbin subdirectory.

o        Run “make MODE=64 run”.  On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in audbin.pl.run.log file.

10.3.1.2 audit_tools

o        cd to audit_tools subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the respective <output>.run.log files.

10.3.1.3 audit_trail_protection

o        cd to audit_trail_protection subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the audit_trail_protection.run.log file.

10.3.1.4 fail-safe

o        cd to fail-safe subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the failsafe.run.log file.

o        To execute a single test, run “./failsafe –t “<name of test>” (for example ./fail-safe –t “log rollover”).  Test results will output to stdout.  The “–d <debug level>” flag can be specified to view debug output.

Note: On zSeries, fail-safe will fail when executed in 32-bit mode.  On 64-bit platforms, executing fail-safe in 32-bit mode is not necessary for EAL4.

10.3.1.5 filter-conf

o        cd to filter-conf subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the filterconf.run.log file.

o        To execute a single test, run “./filterconf –t <name of test> (for example ./filterconf –t login) .  Test results will output to stdout.  The “–d <debug level>” flag can be specified to view debug output.

10.3.1.6 libpam

o        cd to libpam subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the libpam.run.log file.

o        To execute a single test, run “./libpam –t <name of test> (for example ./libpam –t vsftpd).  Test results will output to stdout.  The “–d <debug level>” flag can be specified to view debug output.

10.3.1.7 pam_laus

o        cd to pam_laus subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the pam_laus.run.log file.

o        To execute a single test, run “./pam_laus –t <name of test> (for example ./pam_laus –t vsftpd).  Test results will output to stdout.  The “–d <debug level>” flag can be specified to view debug output.

10.3.1.8 syscalls

o        cd to syscalls subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”. 

o        View the execution results in the syscalls.run.log file.

o        To execute a single test, run “./syscalls –t <name of test> (for example ./syscalls –t settimeofday).  Test results will output to stdout.  The “–d <debug level>” flag can be specified to view debug output.

10.3.1.9 trustedprograms

o        cd to trustedprograms subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the trustedprograms.run.log file.

o        To execute a single test, run “./trustedprograms –t <name of test> (for example ./trustedprograms –t passwd).  Test results will output to stdout.  The “–d <debug level>” flag can be specified to view debug output.

10.3.2 misc_test

o        cd to misc_test directory.

o        Execute “make run”.  On a 64-bit platform, run “make MODE=64 run” to execute the tests in 64-bit mode.  To run the tests in 32-bit mode (31-bit on zSeries), run “make MODE=32 run”.  Note:  This will run fail-safe in 32-bit mode and will hang on zSeries.

o        Test results are directed to log files within each test directory (OpenSSL, at_crontab, databases, eal, ext3_acls, gcov, object_reuse, and permission).

o        A summary report run.log will be created in the current directory.

10.3.2.1 OpenSSL

o        cd to misc_test/OpenSSL.

o        Optionally, export environment variables defined in misc_test/OpenSSL/environment_variables.txt.  Otherwise, the variables are set to default values.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in OpenSSL.run.log.

10.3.2.2 at_crontab

o        cd to at_crontab subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View execution results in at_crontab.run.log file.

10.3.2.3 databases

o        cd to databases subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the respective <output>.run.log files.

10.3.2.4 eal

o        cd to eal subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the <output>.run.log files.

10.3.2.5 ext3_acls

o        cd to ext3_acls subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View execution results in the <output>.run.log files.

10.3.2.6 gcov 

o        Install the gcov kernel rpm (misc_test/gcov/RPMS/kernel-<release>_gcov.<platform>.rpm) using “rpm –Uvh --nodeps --force” (example: “rpm –Uvh --nodeps --force kernel-2.6.5-7.108_gcov.i586.rpm”).

o        Install the lcov rpm (misc_test/gcov/RPMS/lcov-<release>.rpm).

o        Boot gcov instrumented kernel.

o        Run “modprobe gcov-proc”.

o        Run "./gcov_tests ".

o        View <output_directory>/index.html and verify that corresponding functions to each test have been covered.

Note: The gcov tests only apply to xSeries.

10.3.2.7 object_reuse

o        cd to object_reuse subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the respective <output>.run.log files.

10.3.2.8 permission

o        cd to permission subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        View the execution results in the respective <output>.run.log files.

10.3.2.9 proc_sys_perms

o        cd to proc_sys_perms subdirectory.

o        Run “make MODE=64 run”. On a 64-bit platform, you can also run “make MODE=32 run”.

o        You must verify the results manually. See Appendix B for instructions.

10.3.3 LTP

o        cd to LTP directory.

o        Execute “make”.  On a 64-bit platform, run “make MODE=64” to build LTP in 64-bit or “make MODE=32” for LTP 32-bit (31-bit on zSeries).

o        Execute “make run”.  On a 64-bit platform, run “make MODE=64 run” to execute LTP in 64-bit or “make MODE=32 run” to execute LTP in 32-bit (31-bit on zSeries).

o        View the test execution results in the /LTP/ltp.rollup.log and /LTP/ltp.run.log files.

o        To execute a single test case, cd to LTP/ltp-full/testcases/bin directory and run the desired test (for example ./chmod01). Test results will output to stdout.

10.3.4 Manual Tests

o        See Appendix B.

o        Templates must be used for executing manual tests.  The templates are located in the exltp IIOSB project (under /exltp/misc_test/manual_tests).  See the README in the exltp project in IIOSB (under /exltp/misc_test/manual_tests) for instructions on how to use the templates.


Chapter 11.  Quality Information


11.1 System Test Entry Criteria

System test will begin on upon availability of:

o        SUSE SLES 9 ISO images.

o        Official i5 support for Linux.


11.2 System Test Exit Criteria

o        At least 95% of the test cases must pass.

o        No critical defects remain open.

o        Tests executed on IBM xSeries – Model x335 on k_deflt kernel.

o        Tests executed on IBM xSeries – Model x335 on k_smp kernel.

o        Tests executed on IBM zSeries – Model z990.

o        Tests executed on IBM eServer i5 520.

o        Tests executed on IBM eServer p5 520.

o        Tests executed on IBM eServer 325.


11.3 Problem Reporting and Tracking

o        SLES 9 product defects will be recorded in the Distro Service family/SUSE Linux Vendor family in LTC Bugzilla.

o        Test case defects will be recorded in the Bluefortress family in LTC Bugzilla.


Chapter 12. Additional Test Case Information


12.1 Test Tools

o        PAN – Test framework used by the Linux Test Project (LTP).

o        expect / perl-Expect – A tool for automating interactive applications such as login, ssh, etc.


12.2 Security Function/Testcase Mapping

o        The Security Function/Testcase Mapping has been integrated in the SLES 9 Function Specification (FSP).  See sles-eal4-fsp.xls under the EAL Documentation Project in IIOSB (under /ealdoc/SlesEAL4-FunctionSpecification).


Chapter 13. Appendix A – Execution Plan

This is the tentative Execution Plan for SLES 9 EAL4 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.  Key milestones or checkpoints can be viewed in the EAL4 Test Development Project Plan, located in the Line Item Database (Server: D27DBL06/27/A/IBM, Filename: l_dir\LinuxDev.nsf) under line item #1056.06.  You may also refer the EAL4 Test Status document in the Blue Fortress Solutions Teamroom (Server: D01DBM07/01/A/IBM, Filename: 7tua\bluefo1.nsf), located under Blue Fortress Development – EAL4 -> Technical Meeting Status Notes. 

Environment/Checkpoint

Test Cases

Plan Test Start

Actual Test Start

Plan Test Completion

Actual Completion

Functional Verification Test (SLES 9 Beta 5 – GM)

All

05/17/2004

05/17/2004

10/1/2004

10/1/2004

Final Common Criteria Testing

All

10/1/2004

10/18/2004

10/31/2004

10/22/2004


Chapter 14. Appendix B – Manual Tests

Be sure to execute “make clean”, then “make MODE=64” from the top level directory before executing the manual tests.

login (not valid for iSeries or zSeries)

o       From the console, attempt to login as ealuser with an invalid password (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 for ealuser.

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 cable from remote machine to target of evaluation (i.e. system under test). 

o       Target of evaluation machine setup:

o  Add the following line to /etc/inittab on target of evaluation (not valid for pSeries)

S0:2345:respawn:/sbin/agetty -L 9600 ttyS0

o  On pSeries, add the following line to /etc/inittab:

hvs0:12345:respawn:/sbin/agetty –L 9600 hvsi0

o       Reboot machine (or optionally change init level or run "init q").   

o       Remote machine setup:

o  Install minicom on remote machine (rzsz package may need to be installed to resolve dependencies).

o  Invoke minicom from command line (minicom -o -s).

o  From menu that appears select "Serial port setup"

o  Change settings to the following:

A - Serial Device: /dev/ttyS0

B - Lockfile Location: /var/lock

C - Callin Program:

D - Callout Program:

E - Bps/Par/Bits: 9600 8N1

F - Hardware Flow Control: Yes

G - Software Flow Control: No

o    Save settings as default (select "Save setup as dfl" from main menu). 

o    Exit minicom (select "Exit from minicom" from main menu). 

o    Tests:

o  Invoke minicom from remote machine (i.e. run “minicom”).  Note: if prompt is at password, press enter to get a login prompt.

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

o  Add "ttyS0" to the /etc/securetty file on target of evaluation (not valid for pSeries).

o  For pSeries,

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

o       Helpful minicom commands:

o  Ctrl+A  Z  --> display help menu

o  Ctrl+A Q  --> close connection (Select "yes" when prompted to leave without reset).

/etc/inittab & /sbin/init

o       Add the following line to /etc/inittab

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

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

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 one 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       Create a block device:

o       dd if=/dev/zero of=block.img count=2880

o       losetup /dev/loop0 block.img

o       mke2fs /dev/loop0

o       cd to LTP/ltp-full/testcases/bin.

o       Run “./mount01 –D /dev/loop0” (where /dev/loop0 is an umounted block device).  Verify test reports PASS.

o       Run “./mount02 –D /dev/loop0”.  Verify test reports PASS.

o       Run “./mount03 –D /dev/loop0”.  Verify test reports PASS.

o       Run “./mount04 –D /dev/loop0”.  Verify test reports PASS.

o       Cleanup the block device

o       losetup -d /dev/loop0

o       rm block.img  (be sure to run from the directory you created the block device)

Note: On zSeries, test case failures are expected due to differences in errno values. Tests 8 - 13 expect errno 14 (EFAULT) but receive errno 19 (ENODEV) when executed in 32-bit mode. 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 and that all indicate success.

/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.

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

Note: Currently, audit reload and force-reload are not working properly; therefore the "auditf_read: called" lines will not be displayed.  These functions are not supported for EAL4.

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_test.

o       Run “make clean”.

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

o       Create a self signed certificate for stunnel according to the instructions in the SLES 9 configuration guide.

o       Create an stunnel configuration file /tmp/openssltest.conf with the following contents:

   cert = /etc/stunnel/stunnel.pem

ciphers = RC4-SHA

options = NO_TLSv1

 options = NO_SSLv2

pid = /tmp/openssltest.pid

setuid = nobody

setgid = nobody

CAfile = /tmp/openssltest.conf

debug = 6

foreground = yes

output = /tmp/openssltest.log

 

[https]

accept = 443

exec = /bin/cat

execargs = cat /tmp/hello.html

TIMEOUTclose = 0

o       Create a file: /tmp/hello.html with the following contents:

<html>

<h1>

Hello world

</h1>

</html>

o       For each cipher test, from a remote host using Netscape 7.2 (non-OpenSSL based browser), go to Edit-->Preferences. A Preference box will appear under Category.  Go to Privacy & Security --> SSL.  Under the "SSL Protocol Versions" click on the button labeled "Edit Ciphers".  Uncheck every box except for the cipher(s) explicitly identified in the test.

o       Run "/usr/sbin/stunnel /tmp/openssltest.conf".  Note that this command will seem to hang because of the foreground = yes option.

o       In the Netscape 7.2 “Edit Ciphers” window on the remote host, select the SSL3/TLS tab, then select the “128-bit RC4 encryption with RSA and a SHA1 MAC” checkbox.

o       From the remote host using Netscape 7.2, connect to the security target (https://<hostname>).

o       Verify the "Hello World" page is displayed.

o       Run "killall stunnel" (from another terminal window).

o       Change "ciphers = RC4-SHA" to "ciphers = DES-CBC3-SHA" in the /tmp/openssltest.conf file.  See bullet #4.

o       Run "/usr/sbin/stunnel /tmp/openssltest.conf".

o       In the Netscape 7.2 “Edit Ciphers” window on the remote host, select the SSL3/TLS tab, then select the “168-bit Triple DES with RSA and a SHA1 MAC” checkbox.

o       From the remote host using Netscape 7.2, connect to the security target (https://<hostname>).

o       Verify the "Hello World" page is displayed.

o       Change "ciphers = DES-CBC3-SHA " to "ciphers = AES128-SHA" in the /tmp/openssltest.conf file.  See bullet # 4.

o       Run "/usr/sbin/stunnel /tmp/openssltest.conf".

o       In the Netscape 7.2 “Edit Ciphers” window on the remote host, select the Extra SSL3/TLS tab, then select the “128-bit AES encryption with RSA, DHE and a SHA1 MAC”, “128-bit AES encryption with DSA, DHE and a SHA1 MAC” , and “128-bit AES encryption with RSA and a SHA1 MAC” checkboxes.

o       From the remote host using Netscape 7.2, connect to the security target (https://<hostname>).

o       Verify the "Hello World" page is displayed.

o       Change "ciphers = AES128-SHA" to "ciphers = AES256-SHA" in the /tmp/openssltest.conf file.  See bullet # 4.

o       Run "/usr/sbin/stunnel /tmp/openssltest.conf".

o       In the Netscape 7.2 “Edit Ciphers” window on the remote host, select the Extra SSL3/TLS tab, then select the “256-bit AES encryption with RSA, DHE and a SHA1 MAC”, “256-bit AES encryption with DSA, DHE and a SHA1 MAC” , and “256-bit AES encryption with RSA and a SHA1 MAC” checkboxes.

o       From a remote host using Netscape 7.2, connect to the security target (https://<hostname>).

o       Verify the "Hello World" page is displayed.

o       Run "killall stunnel".

o       Run "rm -f /tmp/openssltest* /tmp/hello.html" to cleanup.

proc_sys_perms

These tests are automatically executed by “make MODE=64 run” or “make MODE=32 run” (refer to section 10.3.2).  The results must be manually verified as noted below:

o       All failures are captured in testfileperms.proc.FAIL and testfileperms.sys.FAIL.

o       The testfileperms.proc.FAIL log file may only contain the following expected failures:

o  /proc/tty/driver.serial: errno 13(EACCES) for Owner, Group and Other read access.

o  /proc/kcore: errno 1 (EPERM) for Owner read access.

o  /proc/kmsg: errno 1 (EPERM) for Owner read access.

o  All other failures should be errno 1 (EPERM) for Owner write access.

o       The testfileperms.sys.FAIL log file may only contain the following expected failures:

o  All failures should be errno 13 (EACCES) for Owner read and write access.

o       The /proc and /sys permissions sometimes tries to access pseudo files that no longer exist because a process has exited.  This causes errno 2 (ENOENT) and errno 22 (EINVAL) to occur. 

o       The actual number of failures may vary due to system dynamics.  However, you should never see a case where access is granted when denied was expected.

o       Additionally, the testsfileperms.*.SKIP logs may be viewed to verify the skipped tests only where either “ENODEV” or “EBUSY” was returned, indicating “no device was present” or “the device was busy” respectively.

tmpfs file system

These tests verify the correct behavior of file access permissions for the tmpfs file system.

o       From the test root directory:

o  cp rules.mk /dev/shm                                            //copy rules.mk to tmpfs file system

o  mkdir /dev/shm/misc_test                                     // create test directory in tmpfs file system

o  cp –r misc_test/permission /dev/shm/misc_test    //copy file permission tests to tmpfs file system

o       Change directory to /dev/shm/misc_test/permission

o       Run “make”

o       Run “make run”

o       Verify log each <test>.run.log file does not report any failures

Expected Results

devfileperm.run.log:                   TEST PASSED =  18 , FAILED =  0

dirperm.run.log:                        TEST PASSED =  27 , FAILED =  0

fileperm.run.log:                        TEST PASSED =  27 , FAILED =  0

msqperm.run.log:                      TEST PASSED =  12 , FAILED =  0

namedpipes_fifoperm.run.log:    TEST PASSED =  12 , FAILED =  0

procperm.sh.run.log:                 TEST PASSED =  152 , FAILED =  0

semperm.run.log:                         TEST PASSED =  18 , FAILED =  0

shmperm.run.log:                      TEST PASSED =  18 , FAILED =  0

suid_sgid.run.log:                      TEST PASSED =  6 , FAILED =  0

unixdomainsocketperm.run.log: TEST PASSED =  12 , FAILED =  0


Chapter 15. Appendix C – Expected Results and Failures

LAuS Syscalls Expected Results

xSeries

o       PASSED:  792

o       FAILED:   0

o       SKIPPED:   16

o       fork    4 – fail case N/A.

o       umask     4 – fail case N/A.

o       vfork     4 – fail case N/A.

o       clone     4 – fail case N/A.

eServer p5 520

o       PASSED:  568

o       FAILED:   0

o       SKIPPED:   16

o       fork    4 – fail case N/A.

o       umask     4 – fail case N/A.

o       vfork     4 – fail case N/A.

o       clone     4 – fail case N/A.

eServer i5 520

o       PASSED:  568

o       FAILED:   0

o       SKIPPED:   16

o       fork    4 – fail case N/A.

o       umask     4 – fail case N/A.

o       vfork     4 – fail case N/A.

o       clone     4 – fail case N/A.

zSeries

o       PASSED:  568

o       FAILED:   0

o       SKIPPED:   16

o       fork    4 – fail case N/A.

o       umask     4 – fail case N/A.

o       vfork     4 – fail case N/A.

o       clone     4 – fail case N/A.

eServer 325

o       PASSED:  568

o       FAILED:   0

o       SKIPPED:   16

o       fork    4 – fail case N/A.

o       umask     4 – fail case N/A.

o       vfork     4 – fail case N/A.

o       clone     4 – fail case N/A.

Other Known Failures

failsafe (automated) – The failsafe test for laus_test is expected to fail on zSeries when executed in 32-bit mode (LTC bugzilla #9457).  It is not necessary to run failsafe in 32-bit mode on 64-bit platforms.

sendmsg01 (automated) – On zSeries, a test case failure is expected due to differences in errno values.  The sendmsg01 test for LTP expects errno 95 (EOPNOTSUPP), but receives errno 22 (EINVAL).  The difference in errno values does not pose any security problems.

mount02 (manual) – On zSeries, test case failures are expected due to differences in errno values. Tests 8 - 13 expect errno 14 (EFAULT) but receive errno 19 (ENODEV) when executed in 31-bit mode. The difference in errno values does not pose any security problems.

proc_sys­_perms (automated with manual verification) - The testfileperms.proc.FAIL log file may contain the following expected failures:

o   /proc/tty/driver.serial: errno 13(EACCES) for Owner, Group and Other read access.

o   /proc/kcore: errno 1 (EPERM) for Owner read access.

o   /proc/kmsg: errno 1 (EPERM) for Owner read access.

o   All other failures should be errno 1 (EPERM) for Owner write access.

o   The /proc and /sys permissions sometimes tries to access pseudo files that no longer exist because a process has exited.  This causes errno 2 (ENOENT) and errno 22 (EINVAL) to occur. 

The testfileperms.sys.FAIL log file may contain the following expected failures:

o   All failures should be errno 13 (EACCES) for Owner read and write access.

stime01 - The 31 bit stime system call will set the system time to 0 on an s390x (zSeries) platform. When the LTP test suite is compiled in 31 bit mode on an s390x machine, the stime01 test will not be included in the execution script to prevent the corruption of the system time. A bugzilla report has been opened to notify SUSE of this failure. The following analysis has been made regarding the affect of this failure on the evaluated system:

The documented interface for changing the time is via the shipped
high-level tool "date" which is compiled 64bit and works correctly. See
ECG section 4.12 "Setting the system time and date".
 
Since the broken 31bit interface is available to "root" only, this is not
a security risk that would be exploitable by non-admin users. Also, no
program shipped with the system uses the broken interface, so there is no
risk of an administrator accidentally setting the time to an unexpected
value.


 

End of Document

 


Owner: Kimberly D. Simon