=begin latex

\documentclass{article}
\usepackage{times}
\usepackage{verbatim}

\oddsidemargin=0pt
\evensidemargin=0pt
\topmargin=0pt
\textwidth=6.5in
\textheight=9in
\frenchspacing

% disable hyphenation completely
\hyphenpenalty=10000
\exhyphenpenalty=10000
\sloppy

\begin{document}

\title{\bf Common Criteria EAL4+ Evaluated Configuration Guide for SUSE LINUX Enterprise Server on IBM Hardware}
\author{Klaus Weidner {\tt <klaus@atsec.com>}}
\date{\today; \input{CG-version}}
\maketitle
\thispagestyle{empty}

\newpage

\parindent=0pt
\parskip=6pt plus 2pt minus 1pt

atsec is a trademark of atsec GmbH

IBM, IBM logo, BladeCenter, eServer, System x, System p, System z,
OS/400, PowerPC, POWER3, POWER4, POWER4+, POWER5, S390,
zArchitecture, and z/VM are trademarks or registered
trademarks of International Business Machines Corporation in the
United States, other countries, or both.

Intel and Pentium are trademarks of Intel Corporation in the United States,
other countries, or both.

Java and all Java-based products are trademarks of Sun Microsystems, Inc.,
in the United States, other countries, or both.

Linux is a registered trademark of  Linus Torvalds.

UNIX is a registered trademark of The Open Group in the United States and
other countries.

This document is provided AS IS with no express or implied warranties.  Use
the information in this document at your own risk.

This document may be reproduced or distributed in any form without prior
permission provided the copyright notice is retained on all copies.
Modified versions of this document may be freely distributed provided that
they are clearly identified as such, and this copyright is included intact.

Copyright (c) 2003, 2004, 2007 by atsec GmbH, and IBM Corporation or its wholly owned
subsidiaries.

\newpage

\parskip=0pt

\setcounter{tocdepth}{3}
\tableofcontents

\parskip=6pt plus 2pt minus 1pt

\newpage

\pagestyle{headings}

=end latex

=head1 Introduction

=head2 Purpose of this document

The SUSE LINUX Enterprise Server (SLES) distribution is designed to provide
a secure and reliable operating system for a variety of purposes. Because
security requirements obviously depend on the applications and environment,
it is not possible to simply certify that the system is "secure", a more
precise definition is needed.

The Common Criteria (CC) provides a widely recognized methodology for
security certifications. A CC evaluation is fundamentally a two-step
process, consisting of defining the "security target" which describes the
features that are to be evaluated, and then testing and verifying that the
system actually implements these features with a sufficient level of
assurance.

This document is a security guide that explains how to set up the evaluated
configuration, and provides information to administrators and ordinary users
to ensure secure operation of the system. It is intended to be
self-contained in addressing the most important issues at a high level, and
refers to other existing documentation where more details are needed.

The document primarily addresses administrators, but the section
"Security guidelines for users" is intended for ordinary users of the
system as well as administrators.

Knowledge of the Common Criteria is not required for readers of this
document.

=head2 How to use this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119
<http://www.ietf.org/rfc/rfc2119.txt>.

Note that the terms "SHOULD" and "SHOULD NOT" are avoided in this document.
Requirements are either absolute (and marked with MUST and equivalent
terms), or entirely optional (in the sense of not affecting required
security functions) and marked with RECOMMENDED, MAY or OPTIONAL.

If you follow the requirements in this document when setting up and using
the system, your configuration will match the evaluated configuration.
Certain configuration options are marked as OPTIONAL and you MAY modify them
as needed, but you MUST NOT make other changes, because they will make the
system fail to match the evaluated configuration.

Of course, you MUST always use common sense. This document is not a formal
specification, and legitimate reasons may exist to modify the system setup
in ways not described here if that is necessary for the system to fulfill
its intended purpose. Specifically, applying security patches released by
the vendor is strongly RECOMMENDED even though that will cause a deviation
from the evaluated configuration.

In cases where the requirements and recommendations in this document conflict
with those in other sources (such as the online documentation), the information in
this Configuration Guide has higher precedence. You MUST follow the steps described
here to reach the evaluated configuration, even if other documentation
describes different methods.

The usual convention is used in this guide when referring to manual
pages that are included in the software distribution. For example, the
notation I<ls>(1) means that running the C<man -S 1 ls> command will
display the manual page for the I<ls> command from section one of the
installed documentation. In most cases, the C<-S> flag and the section
number may be omitted from the command, they are only needed if pages
with the same name exist in different sections,

=head2 What is a CC compliant system?

A system can be considered to be "CC compliant" if it matches an evaluated
and certified configuration. This implies various requirements concerning
hardware and software, as well as requirements concerning the operating
environment, users, and the ongoing operating procedures.

Strictly speaking, an evaluation according to the CC represents the results
of investigation of the security properties of the target system according
to defined guidelines. It should not be considered as a guarantee for
fitness for any specific purpose, but should provide help in deciding the
suitability of the system considering how well the intended use fits the
described capabilities. It is intended to provide a level of assurance about the
security functions that have been examined by a neutral third party.

=head3 Hardware requirements

The hardware MUST be the one of the following IBM systems:

	System x: x3550 (rack mount), HS20 and HS21 (blades)
	Opteron (AMD): x3455 (rack mount), LS21 (blade)
	System p: any POWER5 or POWER5+ system
	System z: any z/Architecture compliant system or software

Running the certified software on other similar hardware may result in an
equivalent security level, but the certification does not apply if the
hardware is different from that used for the testing processes during the
evaluation.

=head3 Requirements for the system's environment

The security target covers one or more systems running SLES, networked in a
non-hostile network, with a well-managed and non-hostile user community. It
is not intended to address the needs of an Internet-connected server, or the
case where services are to be provided to potentially hostile users.

It is assumed that the value of the stored assets merits moderately
intensive penetration or masquerading attacks.

You MUST set up the server (or servers) in a physically secure environment,
where they are protected from theft and manipulation by unauthorized
persons.

You MUST ensure that all connections to peripheral devices and all
network connections are protected against tampering, tapping and other
modifications. Using the secured protocols SSHv2 or SSLv3 is
considered sufficient protection for network connections. All other
connections must remain completely within the physically secure server
environment.

=head3 Requirements for connectivity

All components in the network such as routers, switches, and hubs that
are used for communication are assumed to pass the user data reliably
and without modification. Translations on protocols elements
(such as NAT) are allowed as long as those modifications do not lead to a
situation where information is routed to somebody other than the
intended recipient system.

Any other systems with which the system communicates MUST be
under the same management control and operate under the same security
policy constraints.

Be aware that information passed to another system leaves the control
of the sending system, and the protection of this information against
unauthorized access needs to be enforced by the receiving system. If
an organization wants to implement a consistent security policy
covering multiple systems on a network, organizational procedures MUST
ensure that all those systems can be trusted and are configured with
compatible security configurations enforcing an organization wide
security policy. How to do this is beyond the scope of this
Configuration Guide. If you set up a communication link to a system
outside your control, please keep in mind that you will not be able to
enforce any security policy for any information you pass to such a
system over the communication link or in other ways (for example, by
using removable storage media).


=head3 Requirements for administrators

There MUST be one or more competent individuals who are assigned to
manage the system and the security of the information it
contains. These individuals will have sole responsibility for the
following functions: (a) create and maintain roles (b) establish and
maintain relationships among roles (c) Assignment and Revocation of
users to roles. In addition these individuals (as owners of the entire
corporate data), along with object owners will have the ability to
assign and revoke object access rights to roles.

The system administrative personnel MUST NOT be careless, willfully
negligent, or hostile, and MUST follow and abide by the instructions
provided by the administrator documentation.

In CAPP mode, every person that has the ability to perform
administrative actions by switching to root has full control over the
system and could, either by accident or deliberately, undermine
security features of the system and bring it into an insecure
state. This Configuration Guide
provides the basic guidance how to set up and operate the system
securely, but is not intended to be the sole information required for
a system administrator to learn how to operate Linux securely.

It is assumed, within this Configuration Guide, that administrators who
use this guide have a good knowledge and understanding of operating
security principles in general and of Linux administrative commands
and configuration options in particular. We strongly advise that an
organization that wants to operate the system in the evaluated
configuration nevertheless have their administrators trained in
operating system security principles and security functions,
properties, and configuration.

Every organization needs to trust their system administrators not to
deliberately undermine the security of the system. Although the
evaluated configuration includes audit functions that can be used to
make users accountable for their actions, an administrator is able to
stop the audit subsystem and reconfigure it such that his actions no
longer get audited. Well trained and trustworthy administrators are a
key element for the secure operation of the system. This Configuration
Guide provides the additional information a system administrator
should obey when installing, configuring and operating the system in
compliance with the requirements defined in the Security Target for the
Common Criteria evaluation.

=head3 Requirements for the system's users

The security target addresses the security needs of cooperating users in a
benign environment, who will use the system responsibly to fulfill their
tasks.

Authorized users possess the necessary authorization to access at
least some of the information managed by the system and are expected
to act in a cooperating manner in a benign environment.

Note that system availability is I<not> addressed in this evaluation, and a
malicious user could disable a server through resource exhaustion or similar
methods.

The requirements for users specifically include:

=over

=item *

User accounts MUST be assigned only to those users with a need to access the
data protected by the system, and who MUST be sufficiently trustworthy not to
abuse those privileges. For example, the system cannot prevent data from being
intentionally redistributed to unauthorized third parties by an authorized
user.

=item *

Rights for users to gain access and perform operations on information
are based on their membership in one or more roles. These roles are
granted to the users by the administrator. These roles MUST accurately
reflect the users job function, responsibilities, qualifications,
and/or competencies within the enterprise.

=item *

A limited set of users is given the rights to create new data
objects and they become owners for those data objects. The
organization is the owner of the rest of the information under the
control of system.

=item *

Users are trusted to accomplish some task or group of tasks within a
secure IT environment by exercising complete control over their data.

=item *

All users of the system MUST be sufficiently skilled to understand the
security implications of their actions, and MUST understand and follow
the requirements listed in section L<"Security guidelines for
users"> "Security guidelines for users" of this guide. Appropriate
training MUST be available to ensure this.

=back

It is part of your responsibility as a system administrator to verify that
these requirements are met, and to be available to users if they need your
help in maintaining the security of their data.

=head1 Installation

The evaluation covers a fresh installation of SLES, on one of
the supported hardware platforms as defined in section L<"Hardware
requirements"> "Hardware requirements" of this guide.

On the platforms that support virtualization (VM) or secure logical
partitioning (LPAR), other operating systems MAY be installed and
active at the same time as the evaluated configuration. This is if (and only
if) the VM or LPAR configuration ensures that the other operating
systems cannot access data belonging to the evaluated configuration or
otherwise interfere with its operation. Setting up this type of
configuration is considered to be part of the operating environment
and is not addressed in this guide.

On the other platforms, the evaluated configuration MUST be the only
operating system installed on the server.

=head2 Supported hardware

You MAY attach the following peripherals without invalidating the evaluation
results. Other hardware MUST NOT be installed in or attached to the system.

=over

=item *

Any storage devices and backup devices supported by the operating system
(this includes hard disks, CD-ROM drives and tape drives).

=item *

All Ethernet and Token Ring network adapters supported by the operating
system. Modems, ISDN and other WAN adapters are not part of the evaluated
environment.

=item *

PCL 4 or PostScript level 1 compatible printers attached to the system
using a parallel port or USB connection. You MAY also use a network
printer.

=item *

Operator console consisting of a keyboard, video monitor, and
optionally mouse. Additionally, you MAY directly attach supported
serial terminals (see section L<"Using serial terminals"> "Using
serial terminals" of this guide), but I<not> modems, ISDN cards, or
other remote access terminals.

=back

USB keyboards and mice MAY be attached, as some of the supported
hardware platforms would otherwise not have supported console input
devices. If a USB keyboard or mouse is used, it MUST be connected
before booting the operating system, and NOT added later to a running
system. Other hot-pluggable hardware that depends on the dynamic
loading of kernel modules MUST NOT be attached. Examples of such
unsupported hardware are USB and IEEE1394/FireWire peripherals other
than mice and keyboards.

=head2 Selection of install options and packages

This section describes the detailed steps to be performed when installing the
SLES operating system on the target server.

All settings listed here are REQUIRED unless specifically declared
otherwise.

=over

=item 1

It is RECOMMENDED that you disconnect all network connections until
the post-install system configuration is finished. You MAY use a
network if required for the installation (for example when using a NFS
file server instead of CD-ROMs). If you do use a network, you MUST ensure
that this network is secure, for example by directly connecting the
new system to a standalone NFS server with no other network
connections.

=item 1

Verify that the installation CD or DVD is an authentic SUSE
distribution CD/DVD for SLES 10 SP1. The original media are shipped in a
sealed sleeve. 

If using downloaded ISO images, you MUST verify that the MD5 checksums
of the image files are correct. The checksums are shown on the
SUSE/Novell download web page and signed with the SUSE package signing
GPG key. You MUST obtain the SUSE package signing key and ensure that
the key is authentic, for example by getting the key from older SUSE
distribution media that were previously authenticated, or from a
trusted key server or other distribution method.

The ISO images and signed MD5sums are available at these URLs:

 System x/Opteron, System p:
  http://download.novell.com/protected/Summary.jsp?buildid=2FNtOnmkx-w~

 System z:
  http://download.novell.com/protected/Summary.jsp?buildid=HfBRh4TspiE~

After verifying and importing the SUSE package signing key (using
C<gpg --import>), use the following command to check if the signature
is authentic:

	gpg --verify FILENAME

Run C<md5sum *.iso> to view the checksums for the downloaded image
files, and compare them with those shown on the web page.

You MUST use B<SUSE LINUX Enterprise Server 10 SP1>. Make sure that you are
using the appropriate version for your platform, refer to section
L<"Hardware requirements"> "Hardware requirements" of this guide for the
list of supported hardware and the corresponding version needed.

=item 1

Launch the installer program contained on the CD-ROM. The details of
how to do this depend on the hardware platform, please refer to the
installation guide that is part of the printed manual accompanying the
CD.

For example:

=over

=item *

System x, System p, Opteron-based eServer: Insert the first CD and boot from CD-ROM.

=item *

System z: Details depend on the operation mode (VM, LPAR or
native). The process generally involves copying the installer onto the
server and launching the installer using the host's management interface.

=back

=item 1

You MAY choose text-mode installation instead of the default graphical
installation by pressing the C<F2> key at the boot prompt, or add the
option C<console=tty1>.

You MAY also use a serial console to do a text-mode installation. To
do so, connect a serial terminal (or a computer with terminal emulator
software; such a computer MUST be appropriately secure) to the
server's serial port, and boot from the SLES CD. When the boot prompt
appears, add the option C<console=ttyS0> (use the appropriate name of the
serial device if not using ttyS0) and press C<ENTER> to start the
installation.

=item 1

B<Select language:> choose B<English (US)> to ensure that the
messages shown during the installation match those described in this
guide.

=item 1

Accept the B<License agreement>.

=item 1

If prompted (due to having Linux installed already), choose B<New
installation>.

=item 1

Configure B<Clock and Time Zone>:

=over

=item *

RECOMMENDED: keep hardware clock time as B<UTC>.

=item *

RECOMMENDED: set the time zone as appropriate for the server location.

=item *

REQUIRED:  verify that the time displayed is accurate.

=back


=item 1

Next is the B<Installation settings> dialog. Change the settings shown
by clicking on the blue headings, or alternatively by choosing the
corresponding items from the :

=over

=item Keyboard layout

RECOMMENDED: set to match the attached keyboard

=item Mouse

OPTIONAL: set to match the attached mouse. A mouse is not needed for
the evaluated configuration.

=item Partitioning

You MUST use specific settings for the evaluated configuration, using
ext3 file systems with ACL support and including a separate
F</var/log/> partition (for CAPP-compliant auditing). Select either
B<Base partition setup on this proposal> or B<Create custom partition
setup>.

=over

=item *

Configuring a swap partition at least as large as the installed RAM is
RECOMMENDED.

=item *

Set up the REQUIRED F</> (root) and F</var/log> partitions, and as
many additional mounted partitions as appropriate. F</var/log>
REQUIRES at least 100 MB of space in order to be able to install and
launch the audit system, but this does not include the additional
space needed for saved audit logs, please refer to section
L<"Configuring the audit subsystem"> "Configuring the audit subsystem"
of this guide for more information.

It is RECOMMENDED to also use separate partitions for F</var>,
F</home> and F</tmp>. 

Some configurations need a separate F</boot> partition.  This is usually
recognized automatically by the installation program. For System p
machines, you MUST create a partition of type 41 and at least 2MB in
size for boot information, and you do NOT need a separate F</boot>
partition.

The following table shows a RECOMMENDED partitioning scheme together
with minimum sizes for the partitions. Using more space is
RECOMMENDED:

        /boot       75 MB
        /         1200 MB
        /tmp       200 MB
        /home      100 MB
        /var       384 MB
        /var/log   100 MB needed for install, >>1GB for use

=item *

Set the file system type of all partitions to B<ext3>, then choose
B<Fstab Options> and turn on the B<Access Control Lists> check
mark. You MAY activate the additional options "Extended User
Attributes", "No access time", and "Mount read-only" as required.

=back

=item Software

The following patterns are REQUIRED and MUST be marked with a check mark:

	Server Base System

The following patterns are OPTIONAL:

	Novell AppArmor
	C/C++ Compiler and Tools
	Print Server

Other patterns MUST NOT be checked.

On System p, you MUST select the B<64bit Runtime Environment>, under
"System Selection and System Tasks / Base Technologies".

In addition, you MUST select additional packages.  Switch to the
B<Details...> view, and set B<Filter> to B<Search>. Then you can enter
(part of) the package names in the search field and add a check mark
to the package in the search result. For example, search for C<audit>
to quickly find all matching packages.

The packages marked as OPTIONAL are services that are part of the evaluated
configuration but MAY be omitted if you do not need them for your system.
Packages containing documentation files or viewers that this document refers to
are marked as RECOMMENDED, but you MAY omit them.

The installer will automatically choose an appropriate kernel (single
processor or SMP) based on the detected hardware.

On System p, after selecting the packages, Select [I]nformation ->
[V]ersions to show the selected package versions. Use [S]earch to find
the B<I<openssh>> and B<I<pwdutils>> package. Make sure you have the
B<"ppc"> variants of these two packages selected, instead of the
"ppc64" ones.

=over

 ### REQUIRED packages
 amtu                      # Abstract Machine Test Utility
 audit                     # User space tools for 2.6 kernel auditing
 audit-libs                # Dynamic library for libaudit
 pwdutils-plugin-audit     # Plugin for the Linux Audit-Subsystem

 ### OPTIONAL packages
 audit-devel               # Development files for libaudit
 vsftpd                    # FTP daemon (needs xinetd)
 stunnel                   # set up encrypted SSL tunnels

=back

=item Language

choose B<English (US)> to ensure that the
messages shown during the installation match those described in this
guide.

=item Booting (Expert)

MUST keep default (no other OS is permitted on the server).

=item Default Runlevel (Expert)

MUST be set to B<3>.

=back

=item 1

To start the installation: press the B<Accept> and B<Install> buttons.

=item 1

Installation will proceed. Insert the CDs as prompted by the installer.

=item 1

The installer will reboot to continue running on the installed system.

It is RECOMMENDED that you now reconfigure the system to boot from the
newly installed system only (typically the first hard disk) and
disable all other boot methods such as CD-ROM, network boot (PXE) or
floppy disk. If you choose not to do that, you MUST remove the
installation CD-ROM from the drive before rebooting.

=item 1

The installer will continue in text mode, confirm the explanatory text about this.

=item 1

B<Password for "root", the administrator>

=over

=item *

choose according to the password policy (L<"Password policy">)

=item *

in B<Expert Options>, you MUST set Password Encryption: B<MD5>

=back

=item 1

Configure an appropriate B<Hostname and Domain Name>. You MUST NOT use
the I<Change Hostname via DHCP> option.

=item 1

B<Network Configuration>: Configure all installed network cards (zero
or more) as appropriate for the platform. In the case of virtual
network cards on System z, these options are not available.

It is RECOMMENDED that you disconnect all network connections until
the post-install system configuration is finished. You MAY use a
network if required for the installation (for example when using a NFS
file server instead of CD-ROMs). If you do use a network, you MUST
ensure that this network is secure, for example by directly connecting
the new system to a standalone NFS server with no other network
connections.

You MUST NOT install, connect or configure DSL, modems, or ISDN
adapters. You MUST NOT allow remote administration via VNC.

You MAY enable proxy settings if necessary.

Use the B<Change...> menu to configure the B<Network interfaces>.

You MUST use the I<Traditional Method>, NOT the I<NetworkManager>
applet.

You MAY choose to enable or disable the firewall. It is RECOMMENDED to
permit the SSH port.

You MAY enable IPv6.

For each network card, select B<Change...>, then B<Edit> the network
settings. The following options MUST be used for non-virtual network
cards:

=over

=item *

Use B<Static address setup> for each card, and configure an
appropriate B<IP Address> and B<Subnet mask>. You MUST NOT use DHCP.

=item *

Select the B<Host name and name server> dialog, and make the following changes:

=over

=item *

Disable the B<Change host name via DHCP> check box.

=item *

Disable the B<Update name servers via DHCP> check box.

=item *

RECOMMENDED: set the system's B<Host name>.

=item *

OPTIONAL: configure B<Name server> and B<Domain search> entries as required.

=back

=item *

In the B<Routing> dialog, configure the B<Default gateway>
and/or static routes in the routing table as required. You MAY enable
IP forwarding.

=item *

Use the B<Next> button to continue.

=back

=item 1

In the B<Test Internet Connection> dialog, select B<No, Skip This Test>.  Use
the B<Next> button to continue.


=item 1

In the B<Installation Settings> dialog, you MAY change the B<CA
Management> settings if needed. The B<OpenLDAP Server> MUST be
disabled.

=item 1

In the B<User Authentication Method> dialog, select the B<Local>
authentication method.

=item 1

In the B<New Local User> dialog, create an account for one of the
administrators (RECOMMENDED: use the real name of the person doing the
installation).

=over

=item *

Fill out the B<First name>, B<Last name>, B<User login> and
B<Password> fields. The password MUST be chosen as described in
section L<"Password policy"> "Password policy" of this guide.

=item *

It is RECOMMENDED to activate B<Receive System Mail> for
administrators.

=item *

You MUST NOT activate "Auto Login".

=item *

Open the B<User Management> dialog, and choose B<Edit> to activate the
B<Existing Local User> dialog. Edit the B<Password Settings> for the
user you have just created according to the parameters described in
section L<"Setting up login controls"> "Setting up login controls" of
this guide:

  Days before Password Expiration to Issue Warning           5
  Days after Password Expires with Usable Login             -1
  Maximum number of days for the same password              60
  Minimum number of days for the same password               1

The "Expiration date" MAY be left blank.

=item *

While still in the B<Existing Local User> dialog, choose B<Details>,
select the B<Additional group> pane and add membership in the group
B<trusted> for this administrator. B<WARNING:> If you forget this
step, the user will not be permitted to use the I<su> tool. Use the
B<Accept> button to close the dialog.

=item *

You MAY use the B<User Management> tool to create additional
administrator accounts at this time, but it is RECOMMENDED to do this
later, after setup of the evaluated configuration has been completed.

=item *

Use the B<Next> button to continue.

=back

=item 1

If prompted to install additional packages, do so by choosing B<Continue>.

=item 1

Confirm the B<Release Notes> dialog by selecting B<Next>.

=item 1

In the B<Hardware Configuration> dialog, you MUST NOT enable 3D
Acceleration. 

=item 1

Confirm the B<Installation Completed> dialog to start the system.

=item 1

Wait for the freshly installed system to start, and verify that the issue
message printed above the login prompt matches the installed system type and
version.  Then log in as "root" and proceed with the next section.

=back

=head1 Secure initial system configuration

After the initial installation, the operating system is not yet in the
evaluated configuration. The instructions in this section explain how to
achieve that configuration.

After software upgrades or installation of additional packages, these steps
MUST be re-done or at least re-checked to ensure that the configuration
remains secure.

Note that the system does not define audit rules as there is no universally
applicable default for this. Please refer to section L<"Configuring
the audit subsystem"> "Configuring the audit subsystem" of this guide
for more information.

Log in as user 'root' on the system console for the following steps.

=head2 Prerequisites

=head3 Filesystem configuration

You MUST remove the "debugfs" line from the F</etc/fstab> file. This
filesystem is not supported in the evaluated configuration.

=head3 Replace pwdutils package for ppc64 systems

This section applies only to System p.

If the currently installed version of the "pwdutils" package is the
64bit "ppc64" version, you MUST replace it with the 32bit version.
The automated configuration described in the next section will check
for this and will refuse to continue if it detects the wrong version.

Use the following command to check which version you have installed:

 rpm -q --queryformat='%{ARCH}\n' pwdutils

Locate the replacement file "pwdutils-*.ppc.rpm" on the installation
media, and use the "rpm" command to replace the current package, for
example:

 rpm -Uvh --replacepkgs pwdutils-3.0.7.1-17.24.ppc.rpm

=head3 Ensure pam_tally and trusted program binaries match

This section applies only to System p.

The binaries for I<sshd> and the I<pam_tally> program MUST be
installed with the same word size. The following command MUST indicate
"32-bit" for both files:

 file /usr/sbin/sshd /sbin/pam_tally

(The I<sles-eal4> script will perform this check automatically.)

If the word sizes do not match, you MUST reinstall the "ppc" version
of "openssh" and/or "pam" to ensure that both are 32bit.

=head2 Automated configuration of the system

The I<certification-sles-ibm-eal4> package MUST be installed and used
to achieve the evaluated configuration. This RPM package contains EAL4
specific configuration files, updates to the online documentation, and
scripts that set up the evaluated configuration.

Install the RPM as follows:

  rpm -Uvh /root/rpm/certification-sles-ibm-eal4*.noarch.rpm

Please check the file
I</usr/share/doc/packages/certification-sles-ibm-eal4/README-eal4.txt>
from the I<certification-sles-ibm-eal4.rpm> for the latest errata
information.

The automated installation depends on having the correct versions
available for those packages that MUST be updated or added to the
evaluated configuration.

The F<certification-sles-ibm-eal4.rpm> package contains a setup script
that implements the evaluated configuration when run.  You MAY add the
C<-a> switch to run the script automatically, but be aware that this
will change the configuration with with no prompting. Run it with no
arguments to use the default interactive mode (with prompts for
confirmation before making changes):

        /usr/lib/eal4/bin/sles-eal4

When running the script in interactive mode, you MUST permit it to
make each change unless the step is clearly documented to be OPTIONAL.

If the script fails with an error message, verify that all the steps
listed in section L<"Prerequisites"> "Prerequisites" of this guide
have been followed. 

B<WARNING>: The C<sles-eal4> script will reboot the system as the
final step in the process, as described in the manual instructions in
section L<"Reboot and initial network connection"> "Reboot and initial
network connection". Remember to remove any CD-ROM from the drive
and/or configure the system to boot from hard disk only.

After software upgrades or installation of additional packages, you
MUST ensure that the configuration remains secure. Please refer to
sections L<"How to use this document"> "How to use this document" and
L<"Installation of additional software"> "Installation of additional
software" of this guide for additional information. You MAY re-run the
I<sles-eal4> script, but this does not guarantee that you will
be in the evaluated configuration if you have added, deleted,
modified, or replaced system components.

If the script has completed successfully, the remaining steps in this
chapter were done automatically; you MAY skip ahead to section
L<"System operation"> "System operation" of this guide.

The information in the remainder of this section provides background
information about how this configuration was achieved, and mentions
some changes you MAY make to the installed system while still
remaining within the evaluated configuration. It is not intended to be
a complete listing of the changes made to the system. Following the
instructions in section L<"Installation"> "Installation" of this guide
followed by the automated reconfiguration is the only supported method
to set up the evaluated configuration.

=head2 Add and remove packages

Some packages are listed as RECOMMENDED or OPTIONAL in section
L<"Selection of install options and packages"> "Selection of install
options and packages". If you did not select all of those, some of the
following packages will not be present on your system.

In addition to these packages, certain additional software from the
SLES CDs MAY be installed without invalidating the evaluated
configuration. The rules described in the section L<"Installation of
additional software"> "Installation of additional software" MUST be
followed to ensure that the security requirements are not violated.

The following packages are examples of tolerated packages that MAY be added to
the system according to these rules. Note that the software contained in these
packages is not intended to be used with 'root' privileges, but the presence of
the packages does not invalidate the evaluated configuration. The C<sles-eal4>
script does not remove these packages if they are installed on the system:

 Mesa-32bit                krb5-32bit              parted-64bit
 atk-32bit                 krb5-64bit              patch
 audit-devel               libaio-32bit            perl-Digest-HMAC
 audit-libs-32bit          libaio-64bit            perl-Digest-SHA1
 audit-libs-64bit          libaio-devel            perl-HTML-Parser
 autoconf                  libaio-devel-32bit      perl-HTML-Tagset
 automake                  libapparmor-32bit       perl-Net_SSLeay
 bind-libs-32bit           libapparmor-64bit       perl-TimeDate
 bind-libs-64bit           libart_lgpl-32bit       perl-URI
 binutils                  libattr-devel           perl-gettext
 binutils-32bit            libcap-32bit            perl-libwww-perl
 binutils-64bit            libcap-64bit            powerpc-utils
 bison                     libcom_err-32bit        powerpc32
 bison-32bit               libcom_err-64bit        powersave-libs-32bit
 blocxx-64bit              libdrm-32bit            powersave-libs-64bit
 cairo-32bit               libelf-32bit            recode-64bit
 compat-32bit              libgcj-32bit            s390-32
 compat-libstdc++-64bit    libgcrypt-32bit         samba-32bit
 compat-openssl097g-32bit  libgcrypt-64bit         samba-64bit
 compat-openssl097g-64bit  libgpg-error-32bit      sles-preparation-power_en
 cpp                       libgpg-error-64bit      sles-preparation-zseries_en
 cpufrequtils-32bit        libgssapi-32bit         sqlite-32bit
 cpufrequtils-64bit        libgssapi-64bit         sqlite-64bit
 cups-libs-32bit           libidn-32bit            strace
 cups-libs-64bit           libidn-64bit            strace-32bit
 curl-32bit                libjpeg-32bit           strace-64bit
 curl-64bit                libjpeg-64bit           sysfsutils-32bit
 cvs                       liblcms-32bit           sysfsutils-64bit
 db-devel                  liblcms-64bit           sysvinit
 dbus-1-32bit              libmng-32bit            tar
 dbus-1-64bit              libmng-64bit            tcl
 dbus-1-glib-32bit         libnscd-32bit           tcl-32bit
 dbus-1-glib-64bit         libnscd-64bit           tcl-64bit
 device-mapper-32bit       libpcap-32bit           tcpd
 device-mapper-64bit       libpcap-64bit           tcpd-32bit
 expat-32bit               libpng-32bit            tcpd-64bit
 expat-64bit               libpng-64bit            tcsh
 expect                    librtas                 telnet
 flex                      libstdc++-devel         terminfo
 flex-32bit                libtiff-32bit           texinfo
 flex-64bit                libtiff-64bit           timezone
 fontconfig-32bit          libtool-32bit           tk
 freetype2-32bit           libtool-64bit           udev
 freetype2-64bit           libusb-32bit            update-desktop-files
 gcc                       libusb-64bit            usbutils
 gcc-c++                   libxslt-32bit           utempter
 gdb-32bit                 libxslt-64bit           utempter-32bit
 gdb-64bit                 libzio-64bit            utempter-64bit
 gdbm-devel                limal-nfs-server-perl   util-linux
 gdbm-devel-32bit          ltrace-32bit            vim
 gettext-32bit             make                    vsftpd
 gettext-64bit             mono-core-32bit         w3m
 gettext-devel             mpt-firmware            wget
 glib                      ncurses-devel           xinetd
 glib2-32bit               ncurses-devel-32bit     xorg-x11-libs-32bit
 glib2-64bit               ncurses-devel-64bit     yast2
 glibc-devel               numactl                 yast2-bootloader
 glibc-devel-32bit         numactl-64bit           yast2-core
 glibc-devel-64bit         openct-32bit            yast2-country
 glitz-32bit               openct-64bit            yast2-inetd
 gmp-32bit                 openmotif-libs-32bit    yast2-installation
 gmp-devel                 opensc-32bit            yast2-ldap
 gpg-pubkey                opensc-64bit            yast2-ldap-client
 gpm-32bit                 openslp-32bit           yast2-mail-aliases
 gpm-64bit                 openslp-64bit           yast2-mouse
 gtk2-32bit                pam                     yast2-ncurses
 hal-32bit                 pam-32bit               yast2-network
 hal-64bit                 pam-64bit               yast2-online-update
 howtoenh                  pam-modules-32bit       yast2-s390
 hplip17-hpijs             pam-modules-64bit       zlib-devel
 kernel-ppc64              pango-32bit             zlib-devel-32bit
 kernel-source             parted-32bit

=head2 Disable services

Note: The system runlevel as specified in the 'initdefault' entry in
F</etc/inittab> MUST remain at the default setting of '3' for these steps to
be valid.

The following services are REQUIRED for runlevel 3:

	auditd
	cron
	network
	random
	syslog


The following services are OPTIONAL for runlevel 3:

	boot.apparmor
	cups
	dbus
	haldaemon
	kbd
	microcode
	postfix
	sshd
	xinetd

You MUST ensure that all REQUIRED services are active. You MAY enable
or disable services from the OPTIONAL list as suitable for your
configuration. All other services MUST be deactivated.

Use I<insserv ServiceName> to activate a service, and I<insserv -r
ServiceName> to deactivate it.


=head2 Setting up FTP

The evaluated configuration includes OPTIONALLY includes FTP
services. Note that FTP does not provide support for encryption, so
this is only RECOMMENDED for anonymous access to non-confidential
files. If you do not specifically need FTP, it is RECOMMENDED that you
disable the I<vsftpd>(8) service.

The FTP server is started via I<xinetd>, see I<xinetd>(8). The
following is the configuration entry in F</etc/xinetd.d/vsftpd>:

 service ftp
 {
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/vsftpd
 }

The I<vsftpd> service uses several additional configuration files. In
F</etc/vsftpd.conf> the configuration of the ftp daemon is
specified. In addition, the file F</etc/ftpusers> is used for access
control. Users listed in that file can NOT log in via FTP. This file
initially contains all system IDs and the root user. It can be
augmented with other IDs according to the local needs, but the I<root>
entry MUST NOT be removed. The I<ftpusers> file is not checked by the
ftp daemon itself but by a PAM module. Please see section L<"Required
Pluggable Authentication Module (PAM) configuration"> "Required
Pluggable Authentication Module (PAM) configuration" of this guide for
details.

The setup of F</etc/vsftpd.conf> depends on the local needs. Please refer to
I<vsftpd.conf>(5) for details.

The default configuration permits only anonymous FTP. This setting is
therefore only suitable for distribution of public files for which no read
access control is needed.

        anonymous_enable=YES
        local_enable=NO

It is RECOMMENDED disabling anonymous FTP if you do not
need this functionality with the following F</etc/vsftpd.conf> setting:

        anonymous_enable=NO

You MAY enable FTP authentication for local user accounts. The corresponding
setting in F</etc/vsftpd.conf> is:

        local_enable=YES

It is RECOMMENDED to use the more secure alternatives I<sftp>(1) or
I<scp>(1) to copy files among users, and to use FTP only for legacy
applications that do not support this alternative.

=head2 Setting up Postfix

The default settings of the postfix MTA are in accordance with the
EAL4 requirements. It is RECOMMENDED that you set up an alias for root
in the F</etc/aliases> file. Specify one or more user names of administrators
to whom mail addressed to I<root> will be forwarded.

For example, run the following commands (assuming you are starting
from the default Postfix configuration) to forward root mail to user
"jdoe":

        echo "root: jdoe" >>/etc/aliases
        newaliases
        postfix reload

Please see I<postfix>(1), I<master>(8), I<aliases>(5),
I<newaliases>(1), and the documentation in
F</usr/share/doc/packages/postfix/html/> for details.

=head2 Introduction to Pluggable Authentication Module (PAM) configuration

The PAM subsystem is responsible for maintaining passwords and other
authentication data. Because this is a security-critical system,
understanding how it works is very important. In addition to the I<pam>(8)
manual page, full documentation is available in
F</usr/share/doc/packages/pam/text/>, and includes I<"The Linux-PAM System
Administrator's Guide"> (F<pam.txt>) as well as information for writing PAM
applications and modules. Detailed information about modules is available in
F</usr/share/doc/packages/pam/modules/README.pam_*>, as well as manual
pages for individual modules, such as I<pam_pwcheck>(8).

The PAM configuration is stored in the F</etc/pam.d/> directory. Note that
the documentation refers to a file F</etc/pam.conf> that is not used by
SLES (PAM was compiled to ignore this file if the F</etc/pam.d/> directory
exists).

Each service (application) that uses PAM for authentication uses a
I<service-name> to determine its configuration, stored in the
F</etc/pam.d/SERVICE_NAME> file. The special I<service-name> C<OTHER> (case
insensitive) is used for default settings if there are no specific settings.

The configuration file for the service contains one entry for each module, in
the format:

        module-type   control-flag   module-path   args

Comments MAY be used extending from '#' to the end of the line, and entries
MAY be split over multiple lines using a backslash at the end of a line as a
continuation character.

The I<module-type> defines the type of action being done. This can be one of
four types:

=over

=item B<auth>

Authenticates users (determines that they are who they claim to be). It can
also assign credentials, for example additional group memberships beyond those
specified through F</etc/passwd> and F</etc/groups>. This additional
functionality MUST NOT be used.

=item B<account>

Account management not related to authentication, it can also restrict access
based on time of day, available system resources or the location of the user
(network address or system console).

=item B<session>

Manages resources associated with a service by running specified code at the
start and end of the session. Typical usage includes logging and accounting,
and initialization such as auto mounting a home directory.

=item B<password>

Used for updating the password (or other authentication token), for
example when using the I<passwd>(1) utility to change it.

=back

The I<control-flag> specifies the action that will be taken based on the
success or failure of an individual module. The modules are stacked
(executed in sequence), and the I<control-flags> determine which final
result (success or failure) will be returned, thereby specifying the
relative importance of the modules.

Stacked modules are executed in the order specified in the configuration
file.

The I<control-flag> can be specified as either a single keyword, or
alternatively with a more elaborate syntax that allows greater control.
SLES uses only the single keyword syntax by default.

The following keywords control how a module affects the result of the
authentication attempt:

=over

=item B<required>

If this module returns a failure code, the entire stack will return failure.
The failure will be reported to the application or user only after all other
modules in the stack have been run, to prevent leakage of information (for
example, ask for a password even if the entered username is not valid).

=item B<requisite>

Same as B<required>, but return failure immediately not executing the other
modules in the stack. Can be used to prevent a user from entering a password
over an insecure connection.

=item B<sufficient>

Return success immediately if no previous B<required> modules in the stack
have returned failure. Do not execute succeeding modules.

=item B<optional>

The return code of this module is ignored, except if all other modules in
the stack return an indeterminate result (PAM_IGNORE).

=back

The I<module-path> specifies the filename of the module to be run (relative
to the directory F</lib/security/>, and the optional I<args> are passed to
the module - refer to the module's documentation for supported options.


=head2 Required Pluggable Authentication Module (PAM) configuration

You MUST restrict authentication to services that are explicitly specified.
The 'other' fallback MUST be disabled by specifying the F<pam_deny.so>
module for each I<module-type> in the 'other' configuration. This ensures that
access decisions within the PAM system are handled only by the service
specific PAM configuration.

You MUST add the F<pam_wheel.so> module to the 'auth' I<module_type>
configuration for the 'su' service to restrict use of I<su>(1) to
members of the 'trusted' group.

You MUST add the F<pam_tally.so> module to the C<auth> and C<account>
I<module_type> configurations of I<login>, I<sshd>, and
I<vsftpd>. This ensures that accounts are disabled after several
failed login attempts. The F<pam_tally.so> module is used in the C<auth>
stack to increment a counter in the file F</var/log/lastlog>, and in the
C<account> stack to either deny login after too many failed attempts, or
to reset the counter to zero after successful authentication. The
evaluated configuration uses a lockout after five failed attempts,
corresponding to the setting C<deny=5>, you MAY decrease the number
for stricter enforcement. Be aware that this can be used in
denial-of-service attacks to lock out legitimate users. Please refer
to section L<"Managing user accounts"> "Managing user accounts" of
this guide for more information.

You MUST use the F<pam_passwdqc.so> password quality checking module
to ensure that users will not use easily-guessable passwords.

You MUST NOT modify other settings, specifically you MUST use the 'md5' and
'use_cracklib' options for the F<pam_pwcheck.so> module in the F</etc/security/pam_pwdcheck.conf> file.

The 'remember=XX' option must be added to the
F</etc/security/pam_pwcheck.conf> file to force users to create new passwords
and not re-use ones that they had previously, i.e.  to prevent users from
simply alternating between two passwords when asked to change it due to
expiration. XX is any number between 7 and 400.

The system supports many other PAM modules apart from the ones shown
here. In general, you MAY add PAM modules that add additional
restrictions. You MUST NOT weaken the restrictions through
configuration changes of the modules shown here or via additional
modules. Also, you MUST NOT add PAM modules that provide additional
privileges to users (such as the I<pam_console.so> module).

Following are the pam configuration files:

=head3 /etc/pam.d/common-password

 #
 # /etc/pam.d/common-password - password-related modules common to all services
 # CAPP configuration
 #
 # This file is included from other service-specific PAM config files,
 # and should contain a list of modules that define  the services to be
 # used to change user passwords.  The default is pam_unix2 in combination
 # with pam_pwcheck.
 
 # The "nullok" option allows users to change an empty password, else
 # empty passwords are treated as locked accounts.
 #
 # To enable Blowfish or MD5 passwords, you should edit
 # /etc/default/passwd.
 #
 # Alternate strength checking for passwords should be configured
 # in /etc/security/pam_pwcheck.conf.
 #
 # pam_make can be used to rebuild NIS maps after password change.
 #
 password requisite     pam_passwdqc.so ask_oldauthtok=update check_oldauthtok
 password requisite     pam_pwcheck.so  use_first_pass use_authtok
 password required      pam_unix2.so    use_first_pass use_authtok
 
=head3 /etc/pam.d/login

This file configures the behavior of the I<login> program.  It allows root
login only for terminals configured in F</etc/securetty>.  If the file
F</etc/nologin> is present, then only root can log in.  The optional
I<pam_env> module MAY be used to set environment variables from
F</etc/security/pam_env.conf>.  The optional pam_mail module MAY be used to
notify the user that there is new mail.  The I<pam_tally> module MUST be used
to block the user after 5 failed login attempts.  The optional I<pam_limits>
module MAY be used to enforce resource limits via
F</etc/security/limits.conf>.

The I<pam_loginuid.so> module is by default configured to be C<optional>
instead of C<required>, which assumes that all terminals available for
login are in physically secure locations and accessible only for
authorized administrators. This permits administrators to log in on
the console even if the audit subsystem is not available. If any
serial terminals are attached and available for arbitrary users, you
MUST specify the I<pam_loginuid.so> module to be C<required> to ensure the
CAPP-compliant fail-secure operating mode that disables login if audit
is not working. Please refer to section L<"Using serial terminals">
"Using serial terminals" of this guide for more information.

 #%PAM-1.0
 auth     required       pam_securetty.so
 auth     required       pam_tally.so deny=5 onerr=fail
 auth     include        common-auth
 auth     required       pam_nologin.so
 account  include        common-account
 account  required       pam_tally.so
 password include        common-password
 session  include        common-session
 session  required       pam_lastlog.so nowtmp
 session  required       pam_resmgr.so
 session  optional       pam_mail.so standard
 session  optional       pam_loginuid.so     # no lockout on failure


=head3 /etc/pam.d/sshd

This file configures the PAM usage for SSH.

 #%PAM-1.0
 auth     required       pam_securetty.so # deny root login in evaluated config
 auth     required       pam_tally.so deny=5 onerr=fail
 auth     include        common-auth
 auth     required       pam_nologin.so
 account  include        common-account
 account  required       pam_tally.so
 password include        common-password
 session  include        common-session
 session  required       pam_loginuid.so require_auditd


=head3 /etc/pam.d/su

This file configures the behavior of the 'su' command. Only users in the
trusted group can use it to become 'root', as configured with the I<pam_wheel>
module.

 #%PAM-1.0
 auth     sufficient     pam_rootok.so
 auth     required       pam_wheel.so use_uid group=trusted
 auth     include        common-auth
 account  include        common-account
 password required       pam_deny.so
 session  include        common-session
 session  optional       pam_xauth.so

Forcing the root user to change the root password is not desired here,
therefore the I<pam_unix2.so> module is absent in the I<password>
branch and I<pam_deny.so> is used instead.


=head3 /etc/pam.d/vsftpd

This file configures the authentication for the FTP daemon. With the listfile
module, users listed in /etc/ftpusers are denied FTP access to the system.

 #%PAM-1.0
 auth       required     pam_listfile.so item=user sense=deny \
                         file=/etc/ftpusers onerr=succeed
 auth     required       pam_tally.so deny=5 onerr=fail
 auth     include        common-auth
 account  include        common-account
 account  required       pam_tally.so
 account  required       pam_loginuid.so require_auditd
 password required       pam_deny.so
 session  include        common-session


Note that the FTP protocol has no provisions for changing passwords,
therefore the I<pam_unix2.so> module is absent in the I<password>
branch and I<pam_deny.so> is used instead.

=head3 /etc/pam.d/crond

This file configures the cron service to ensure that tasks run on a
user's behalf have the correct associated audit uid.

 #
 # The PAM configuration file for the cron daemon
 #
 #
 auth     sufficient     pam_rootok.so
 auth     include        common-auth
 account  include        common-account
 password include        common-password
 session  include        common-session
 session  required       pam_loginuid.so require_auditd


=head3 /etc/security/pam_pwcheck.conf

This file contains the default options for the I<pam_pwcheck> module. This
makes it easier to set a global policy. The I<md5> option enables long
passwords (up to 127 characters, see also the limit in F</etc/login.defs>,
and the I<use_cracklib> option activates password quality checks against
standard dictionary and permutation attacks.  The I<remember> option ensures
that the user does not reuse passwords by keeping track of the specified
number of previously used passwords in the file F</etc/security/opasswd>.

 password:   md5 cracklib remember=7

=head3 /etc/security/pam_unix2.conf

This file contains the default options for the I<pam_unix2> module. This makes
it easier to set a global policy. The I<md5> option enables long passwords (up
to 127 characters, see also the limit in F</etc/login.defs>.
The I<trace> option activates session tracing (start/stop) via I<syslog>.

 auth:
 account:
 password:   md5
 session:    trace

=head2 Setting up login controls

The system supports various options to control log ins in
F</etc/login.defs>.  Comments in the file explain the options and
values that MUST be set for the EAL4 evaluated configuration.  

The UMASK entry sets the I<default> permissions for new home
directories to the most restrictive setting.  Users MAY assign
different permissions as described in section L<"Access control for
files and directories"> "Access control for files and directories" of
this guide. Note that the default umask for logged-in users is set in
the F</etc/profile> file, not here.

=head3 Maintaining I<cracklib> dictionaries

The dictionary files used by I<cracklib> are stored in F</usr/lib/>:

        /usr/lib/cracklib_dict.hwm
        /usr/lib/cracklib_dict.pwd
        /usr/lib/cracklib_dict.pwi

To create custom dictionary files instead of the supplied ones, the command
F</usr/sbin/create-cracklib-dict> MAY be used as follows:

        /usr/sbin/create-cracklib-dict wordlist wordlist ...

This will generate a new set of dictionary files from the supplied word lists.
Suggested word lists are included in the source RPM package of I<cracklib>. We
RECOMMEND adding dictionaries for your local language and other languages
likely to be known by your user community.

=head2 Configuring the boot loader

You MUST set up the server in a secure location where it is protected
from unauthorized access. Even though that is sufficient to protect
the boot process, it is RECOMMENDED to configure the following
additional protection mechanisms:

=over

=item *

Ensure that the installed system boots exclusively from the disk
partition containing SLES, and not from floppy disks, USB drives,
CD-ROMs, network adapters, or other devices.

=item *

Ensure that this setting cannot be modified, for example by using a
BootProm/BIOS password to protect access to the configuration.

=back

=head3 GRUB boot loader configuration

The GRUB boot loader is used on the x86 and Opteron platforms. It is
highly configurable, and permits flexible modifications at boot time
through a special-purpose command line interface. Please refer to the
I<grub>(8) man page or run C<info grub> for more information.

=over

=item *

Use the C<password> command in F</boot/grub/menu.lst> to prevent
unauthorized use of the boot loader interface. Using md5 encoded
passwords is RECOMMENDED, run the command I<grub-md5-crypt> to
generate the encoded version of a password.

=item *

Protect all menu entries other than the default SLES boot with the
C<lock> option, so that the boot loader will prompt for a password
when the user attempts to boot from other media (such as a floppy) or
sets other non-default options for the boot process. To implement
this, add a line containing just the keyword C<lock> after the C<title>
entry in the F</boot/grub/menu.lst> file.

=item *

Remove group and world read permissions from the grub configuration file if
it contains a password by running the following command:

        chmod 600 /boot/grub/menu.lst

All changes to the configuration take effect automatically on the next
boot, there is no need to re-run an activation program.

=back

The following example of the F</boot/grub/menu.lst> configuration file shows
RECOMMENDED settings:

  color white/blue black/light-gray
  default 0
  timeout 8
  password --md5 $1$O471l/$H/JW2MYeugX6Y1h3v.1Iz0

  title linux
     kernel (hd0,1)/boot/vmlinuz root=/dev/sda2
     initrd (hd0,1)/boot/initrd
  title failsafe
     lock
     kernel (hd0,1)/boot/vmlinuz.shipped root=/dev/sda2 ide=nodma apm=off \
        acpi=off vga=normal nosmp disableapic maxcpus=0 3
     initrd (hd0,1)/boot/initrd.shipped

Note that the configuration shown here might not be exactly the configuration used on
the installed system, depending on the kernel options needed for the hardware.

=head3 Yaboot boot loader configuration

Yaboot is used on the System p machines, it is an OpenFirmware-based
boot loader, and can be reconfigured at boot time from a specialized
command line.

Yaboot and GRUB are very similar, both support MD5-encrypted passwords
specified in the configuration file. 

The configuration is contained in the F</etc/lilo.conf> file. Running
the I<lilo> tool creates the F<yaboot.conf> file based on the
information in the F</etc/lilo.conf> file.

You need to re-run the I<lilo>(8) tool when you have modified the
configuration file, this is however not necessary if you replace a
kernel and keep all path names unchanged.

Please refer to the "SuSE Linux Enterprise Server Installation Guide"
for System p, the I<yaboot.conf>(5) and I<lilo>(8)
manual pages, and the yaboot HOWTO for more information:

        http://penguinppc.org/projects/yaboot/doc/yaboot-howto.shtml

=head3 ZIPL boot loader configuration

The ZIPL boot loader is used on the zSeries mainframe when the system
is set up using the VM virtualization layer. In this context,
"booting" refers to the initial program load (IPL) done from the CP
command prompt, which affects only a single specific Linux instance
(a.k.a. "partition", which refers to the running system and not the
disk partition in this context).

Configuration of the VM system is beyond the scope of this
document. You MUST ensure that the configuration settings and virtual
devices used are only accessible to the authorized administrators. Do
NOT use unencrypted 3270 sessions for console access on insecure
networks.

ZIPL writes a boot record on the virtual disk (DASD) used by this
Linux instance, this boot record then proceeds to load and run the
Linux kernel itself. The C<zipl> command must be re-run after any
kernel or boot argument modifications. Please refer to the I<zipl>(8)
man page for more information.

The following example shows a typical F</etc/zipl.conf> file:

        # Generated by YaST2
        [defaultboot]
        default=ipl

        [ipl]
        target=/boot/zipl
        image=/boot/kernel/image
        ramdisk=/boot/initrd
        parameters="dasd=0200 root=/dev/dasda1"

=head2 Reboot and initial network connection

I<-- This concludes the sections covered by the automated configuration script -->

After all the changes described in this chapter have been done, you
MUST reboot the system to ensure that all unwanted tasks are stopped,
and that the running kernel, modules and applications all correspond
to the evaluated configuration.

Please make sure that the boot loader is configured correctly for your
platform.

Remember to remove any CD-ROM from the drive and/or configure the
system to boot from hard disk only.

The system will then match the evaluated configuration. The server MAY
then be connected to a secure network as described above.

=head1 System operation

To ensure that the systems remains in a secure state, special care MUST be
taken during system operation.

=head2 System startup, shutdown and crash recovery

Use the I<shutdown>(8), I<halt>(8) or I<reboot>(8) programs as needed to shut
down or reboot the system.

When powered on (or on initial program load of the logical partition on
a host system), the system will boot into the SLES operating
system. If necessary (for example after a crash), a filesystem check will be
performed automatically. In rare cases manual intervention is
necessary, please refer to the I<e2fsck>(8) and I<debugfs>(8)
documentation for details in this case.

In case a nonstandard boot process is needed (such as booting from
floppy disk or CD-ROM to replace a defective hard drive), interaction
with the boot loader and/or the host's management system can be used
to modify the boot procedure for recovery.

For example, on systems using the I<grub> boot loader you can use the
following commands to launch a shell directly from the kernel,
bypassing the normal init/login mechanism:

        # view the current grub configuration
        grub> cat (hd0,1)/boot/grub/menu.lst

        # manually enter the modified settings
        grub> kernel (hd0,1)/boot/vmlinuz root=/dev/sda1 init=/bin/sh
        grub> initrd (hd0,1)/boot/initrd
        grub> boot

Please refer to the relevant documentation of the boot loader, as well
as the SLES administrator guide, for more information.

=head2 Backup and restore

Whenever you make changes to security-critical files, you MAY need to be able
to track the changes made and revert to previous versions, but this is not
required for compliance with the evaluated configuration.

The I<star>(1) archiver is RECOMMENDED for backups of complete
directory contents, please refer to section L<"Data import /
export"> "Data import / export" of this guide. Regular backups of the following
files and directories (on removable media such as tapes or CD-R, or on a
separate host) are RECOMMENDED:

        /etc/
        /var/spool/cron/

Depending on your site's audit requirements, also include the contents
of F</var/log/> in the backup plan. In that case, the automatic daily
log file rotation needs to be disabled or synchronized with the backup
mechanism, refer to sections L<"System logging and accounting">
"System logging and accounting" and L<"Configuring the audit
subsystem"> "Configuring the audit subsystem" of this guide for more
information.

You MUST protect the backup media from unauthorized access, because
the copied data does not have the access control mechanisms of the
original file system. Among other critical data, it contains the
secret keys used by the I<SSH> and I<stunnel> servers, as well as the
F</etc/shadow> password database. Store the backup media at least as
securely as the server itself.

A RECOMMENDED method to track changes is to use a version control system. RCS
is easy to set up because it does not require setting up a central repository
for the changes, and you can use shell scripting to automate the change
tracking. RCS is not included in the evaluated configuration, see
I<rcsintro>(1) in the rcs RPM package for more information. Alternatively, you
can create manually create backup copies of the files and/or copy them to
other servers using I<scp>(1).

=head2 Gaining superuser access

System administration tasks require superuser privileges.  Since directly
logging on over the network as user 'root' is disabled, you MUST first
authenticate using an unprivileged user ID, and then use the C<su> command to
switch identities. Note that you MUST NOT use the 'root' rights for anything
other than those administrative tasks that require these privileges, all
other tasks MUST be done using your normal (non-root) user ID.

You MUST use exactly the following I<su>(1) command line to gain
superuser access:

        /bin/su -

This ensures that the correct binary is executed irrespective of PATH
settings or shell aliases, and that the root shell starts with a clean
environment not contaminated with the starting user's settings. This is
necessary because the F<.profile> shell configuration and other similar
files are writable for the unprivileged ID, which would allow an attacker
to easily elevate privileges to root if able to subvert these settings.

Administrators MUST NOT add any directory to the root user's PATH that
are writable for anyone other than 'root', and similarly MUST NOT use or
execute any scripts, binaries or configuration files that are writable for
anyone other than 'root', or where any containing directory is writable
for a user other than 'root'.

=head2 Installation of additional software

Additional software packages MAY be installed as needed,
provided that they do not conflict with the security requirements.

Any additional software added is not intended to be used with superuser
privileges. The administrator MUST use only those programs that are part of the
original evaluated configuration for administration tasks, except if the
administrator has independently ensured that use of the additional software is
not a security risk.

Administrators MAY add scripts to automate tasks as long as those only depend
on and run programs that are part of the evaluated configuration.

The security requirements for additional software are:

=over

=item *

Kernel modules other than those provided as part of the evaluated
configuration MUST NOT be installed or loaded. You MUST NOT load the
I<tux> kernel module (the in-kernel web server is not supported). You
MUST NOT add support for non-ELF binary formats or foreign binary
format emulation that circumvents system call auditing. You MUST NOT
activate I<knfsd> or export NFS file systems.

=item *

Device special nodes MUST NOT be added to the system.

=item *

SUID root or SGID root programs MUST NOT be added to the system.
Programs which use the SUID or SGID bits to run with identities other than
'root' MAY be added.

=item *

The content, permissions, and ownership of all existing filesystem objects
(including directories and device nodes) that are part of the evaluated
configuration MUST NOT be modified. Files and directories MAY be added to
existing directories provided that this does not violate any other
requirement.

=item *

Programs automatically launched with 'root' privileges MUST NOT be added to the
system. Exception: processes that I<immediately> and I<permanently> switch to a
non privileged identity on launch are permitted, for example by using C<su USERID -c
LAUNCH_COMMAND> in the startup file, or alternatively by using the
I<setgroups>(2), I<setgid>(2) and I<setuid>(2) system calls in a binary.
(I<seteuid>(2) etc. are insufficient.)

Automatic launch mechanisms are:

=over

=item *

Entries in F</etc/inittab>

=item *

Executable files or links in F</etc/init.d/> and its subdirectories

=item *

Entries in F</etc/xinetd.conf>

=item *

Scheduled jobs using C<cron> (including entries in F</etc/cron*> files) or
C<at>

=back

=back

Examples of programs that usually do not conflict with these requirements
and MAY be installed are compilers, interpreters, network services
running with non-root rights, and similar programs. The requirements listed
above MUST be verified in each specific case.

=head2 Scheduling processes using cron

The I<cron>(8) program schedules programs for execution at regular intervals.
Entries can be modified using the I<crontab>(1) program - the file format is
documented in the I<crontab>(5) manual page.

You MUST follow the rules specified for installation of additional programs
for all entries that will be executed by the 'root' user. Use non-root
crontab entries in all cases where 'root' privileges are not absolutely
necessary.

Errors in the non interactive jobs executed by C<cron> are reported
in the system log files in F</var/log/>, and additionally via e-mail to the
user who scheduled it.

Permission for users to schedule jobs with C<cron> is controlled
through the following I<allow> and I<deny> files:

        /etc/cron.allow
        /etc/cron.deny

The I<allow> file has precedence if it exists, then only those users
whose usernames are listed in it are permitted to use the service. If
it does not exist, the I<deny> file is used instead and all users who
are I<not> listed in that file can use the service. Note that the
contents of these files are only relevant when the scheduling commands
are executed, and changes have no effect on already scheduled
commands.

In the SLES distribution, the I<allow> file does not exist, and the I<deny>
file is used to prevent system-internal IDs and/or guest users from
using the service. By default, the evaluated configuration permits
all non-system users to use I<cron>.

It is RECOMMENDED to restrict the use of I<cron> to human
users and disallow system accounts from using these mechanisms. For
example, the following commands add all system accounts other than
root to the I<deny> files:

  awk -F: '{if ($3>0 && $3<100) print $1}' /etc/passwd >>/etc/cron.deny
  chmod 600 /etc/cron.deny

Administrators MAY schedule jobs that will be run with the privileges
of a specified user by editing the file F</etc/crontab> with an
appropriate username in the sixth field. Entries in F</etc/crontab>
are not restricted by the contents of the I<allow> and I<deny> files.

You MAY create a I</etc/cron.allow> file to
explicitly list users who are permitted to use this service. If you
do create the file, it MUST be owned by the user 'root' and have
file permissions 0600 (no access for group or others).

=head2 Mounting filesystems

If any filesystems need to be mounted in addition to those set up at
installation time, appropriate mount options MUST be used to ensure
that mounting the filesystem does not introduce capabilities that
could violate the security policy.

The special-purpose F<proc>, F<sysfs>, and F<tmpfs> filesystems are
part of the evaluated configuration. These are virtual filesystems
with no underlying physical storage, and represent data structures in
kernel memory. Access to contents in these special filesystems is
protected by the normal discretionary access control policy and
additional permission checks. 

Note that changing ownership or permissions of virtual files and
directories is generally NOT supported for the F<proc> and F<sysfs>
filesystems (corresponding to directories F</proc/> and F</sys/>), and
attempts to do so will be ignored or result in error messages.

Note that use of the F<usbfs> filesystem type is NOT permitted (and
not needed) in the evaluated configuration.

A new file system can be integrated as part of the evaluated
configuration, for example by installing an additional hard disk,
under the following conditions:

=over 4

=item *

The device is protected against theft or manipulation in the same way
as the server itself, for example by being installed inside the server.

=item *

One or more new, empty, file systems in EXT3 format are created on
it.

=item *

The file systems are mounted using the C<acl> option, for example with
the following setting in the F</etc/fstab> file:

        /dev/sdc1 /home2 ext3 acl 1 2

Existing files and directories MAY then be moved onto the new file systems.

=item *

If a device containing a file system is ever removed from the system,
the device MUST be stored within the secure server facility, or
alternatively MUST be destroyed in a way that the data on it is
reliably erased.

=back


Alternatively, media MAY be accessed without integrating them into the
evaluated configuration, for example CD-ROMs or DVDs.

CD/DVD devices MUST be accessed using the C<iso9660> filesystem
type. Using the C<subfs> automounter is NOT permitted in the evaluated
configuration. See also section L<"Filesystem configuration">
"Filesystem configuration" of this guide.

The following mount options MUST be used if the filesystems contain
data that is not part of the evaluated configuration:

        ro,nodev,nosuid

Adding the I<noexec> mount option to avoid accidental execution of
files or scripts on additional mounted filesystems is RECOMMENDED.

Note that these settings do not completely protect against malicious
code and data, you MUST also verify that the data originates from a
trustworthy source and does not compromise the server's
security. Specifically, be aware of the following issues:

=over

=item *

Even unprivileged programs and scripts can contain malicious code that
uses the calling user's rights in unintended ways, such as corrupting
the user's data, introducing trojan horses in the system, attacking
other machines on the network, revealing confidential documents,
or sending unsolicited commercial e-mail ("spam").

=item *

Data on the additional filesystem MUST have appropriate access rights to
prevent disclosure to or modification by unauthorized users. Be aware that
imported data may have been created using user names and permissions that do
not match your system's security policies.

=item *

You MUST NOT write data on removable file systems such as floppy
disks, since it cannot be adequately protected by the system's access
control mechanisms after being removed from the system. Please refer
to section L<"Backup and restore"> "Backup and restore" of this guide
for more information regarding non-filesystem-based backup.

=back

Each new file system MUST be mounted on an empty directory that is not used for
any other purpose. It is RECOMMENDED using subdirectories of F</mnt> for temporary
disk and removeable storage media mounts.

For example:

  # mount /dev/cdrom /media/cdrom -t iso9660 -o ro,nodev,nosuid,noexec

You MAY also add an equivalent configuration to F</etc/fstab>, for example:

  /dev/cdrom /media/cdrom iso9660 ro,noauto,nodev,nosuid,noexec 0 0

You MUST NOT include the I<user> flag, ordinary users are not permitted to
mount filesystems. This is also enforced by the deletion of the SUID bit on
the I<mount> command.

=head2 Managing user accounts

Use the I<useradd>(8) command to create new user accounts, then use
the I<passwd>(1) command to assign an initial password for the
user. Alteratively, if the user is present when the account is
created, permit them to choose their own password. Refer to the manual
pages for I<useradd>(8) and I<passwd>(1) for more information.

If you assign an initial password for a new user, you MUST transfer
this initial password in a secure way to the user, ensuring that no
third party gets the information. For example, you can tell the
password to a user personally known to you. If this is not possible,
you MAY send the password in written form in a sealed letter. This
applies also when you set a new password for a user in case the user
has forgotten the password or it has expired. You MUST advise the
user that he MUST change this initial password when he first logs into
the system and select his own password in accordance with the rules
defined in section L<"Password policy"> "Password policy" of this
guide.

You MUST NOT use the C<-p> option to I<useradd>(8), specifying a
password in that way would bypass the password quality checking
mechanism.

The temporary password set by the administrator MUST be changed by the
user as soon as possible. Use the I<chage>(8) command with the C<-d>
option to set the last password change date to a value where the user
will be reminded to change the password. The RECOMMENDED value is
based on the settings in F</etc/login.defs> and is equivalent to
today's date plus PASS_WARN_AGE minus PASS_MAX_DAYS.

Example:

        useradd -m -c "John Doe" jdoe
        passwd jdoe
        chage -d $(date +%F -d "53 days ago") jdoe

The C<-m> option to I<useradd>(8) creates a home directory for the
user based on a copy of the contents of the F</etc/skel/>
directory. Note that you MAY modify some default configuration settings for
users, such as the default I<umask>(2) setting or time zone, by
editing the corresponding global configuration files:

        /etc/profile
        /etc/bash.bashrc
        /etc/csh.cshrc

If necessary, you MAY reset the user's password to a known value using
C<passwd I<USER>>, and entering the new password. You cannot recover the
previously used password, since the hash function used is not reversible.

You MAY use the I<usermod>(8) command to change a user's properties. For
example, if you want to add the user 'jdoe' to the I<trusted> group, you could
use the following:

        # List the groups the user is currently a member of:
        groups jdoe

        # Add the additional group
        usermod -G $(su jdoe -c groups | sed 's/ /,/g'),trusted jdoe

Users MAY be locked out (disabled) using C<passwd -l I<USER>>, and re-enabled
using C<passwd -u I<USER>>.

The I<pam_tally.so> PAM module enforces automatic lockout after
excessive failed authentication attempts, as described in section
L<"Required Pluggable Authentication Module (PAM) configuration">
"Required Pluggable Authentication Module (PAM) configuration" of this
guide. Use the program I<pam_tally> to view and reset the counter if
necessary, as documented in the file
F</usr/share/doc/pam-*/txts/README.pam_tally>. Note that the
I<pam_tally> mechanism does not I<prevent> password guessing attacks, it
only prevents I<use> of the account after such an attack has been
detected. Therefore, you MUST assign a new password for the user
before reactivating an account. For example:

        # view the current counter value
        pam_tally --user jdoe

        # set new password, and reset the counter
        passwd jdoe
        pam_tally --user jdoe --reset

The I<chage>(1) utility MAY be used to view and modify the expiry settings for
user accounts. Unprivileged users are able to view but not modify their own
expiry settings.

The I<userdel>(8) utility removes the user account from the system, but does
not remove files outside the home directory (and the mail spool file), or
kill processes belonging to this user.  Use C<kill> (or reboot the system)
and C<find> to do so manually if necessary, for example:

        # Which user to delete?
        U=jdoe

        # Lock user account, but don't remove it yet
        passwd -l $U

        # Kill all user processes, repeat if needed (or reboot)
        kill -9 `ps -la --User $U|awk '{print $4}'`

        # Recursively remove all files and directories belonging to user
        # (Careful - this may delete files belonging to others if they
        # are stored in a directory owned by this user.)
        find / -depth \( ! -fstype ext3 -prune -false \) \
                -o -user $U -exec rm -rf {} \;

        # Remove cron jobs
        crontab -u $U -r

        # Now delete the account
        userdel $U

If you need to create additional groups or modify existing groups, use
the I<groupadd>(8), I<groupmod>(8) and I<groupdel>(8) commands.

Group passwords are NOT supported in the evaluated configuration, and have
been disabled by removing the SUID bit from the I<newgrp>(8) program. You
MUST NOT re-enable this feature and MUST NOT use I<passwd>(1) with the
C<-g> switch or the I<gpasswd>(1) command to set group passwords.

=head2 Using serial terminals

You MAY attach serial terminals to the system. They are activated by
adding an entry in the file F</etc/inittab> for each serial terminal
that causes I<init>(8) to launch an I<agetty>(8) process to monitor
the serial line. I<agetty> runs I<login>(1) to handle user
authentication and set up the user's session.

If you use serial terminals and require the CAPP-compliant fail-safe
audit mode, you MUST ensure that the file F</etc/pam.d/login> is
configured to C<require> the I<pam_loginuid.so> module in the C<session>
stack. Please refer to section L<"/etc/pam.d/login">
"/etc/pam.d/login" of this guide for more information about the needed
PAM configuration.

For example, adding the following line to F</etc/inittab> activates a
VT102-compatible serial terminal on serial port /dev/ttyS1,
communicating at 19200 bits/s:

        S1:3:respawn:/sbin/agetty 19200 ttyS1 vt102

The first field MUST be an unique identifier for the entry (typically
the last characters of the device name). Please refer to the
I<agetty>(8) and I<inittab>(5) man pages for further information about
the format of entries.

You MUST reinitialize the I<init> daemon after any changes to
F</etc/inittab> by running the following command:

        init q

=head2 SYSV shared memory and IPC objects

The system supports SYSV-compatible shared memory, IPC objects, and message
queues. If programs fail to release resources they have used (for example, due to a
crash), the administrator MAY use the I<ipcs>(8) utility to list information
about them, and I<ipcrm>(8) to force deletion of unneeded objects. Note that
these resources are also released when the system is rebooted.

For additional information, please refer to the I<msgctl>(2), I<msgget>(2),
I<msgrcv>(2), I<msgsnd>(2), I<semctl>(2), I<semget>(2), I<semop>(2),
I<shmat>(2), I<shmctl>(2), I<shmdt>(2), I<shmget>(2) and I<ftok>(3) manual
pages.

=head2 Configuring secure network connections with I<stunnel>

=head3 Introduction

The I<stunnel> program is a flexible and secure solution for setting
up encrypted network connections, enabling the use of strong
encryption even for applications that are not able to use encryption
natively. I<stunnel> uses the OpenSSL library for its encryption
functions, and the corresponding I<openssl>(1) command line tool for
key management.

Stunnel has three main operating modes:

=over

=item *

Accept incoming SSL-encrypted TCP connections, and run a specific
program to handle the request.

This is similar to how I<xinetd> launches programs, and any program
compatible with I<xinetd> can also be used for this purpose. It must
read and write the communication data on the I<stdin> and I<stdout>
file descriptors and stay in the foreground. I<stunnel> also supports
switching user and group IDs before launching the program.

=item *

Open a SSL connection to a remote SSL-capable TCP server, and copy
data to and from I<stdin> and I<stdout>.

=item *

Bind a TCP port to accept incoming unencrypted connections, and
forward data using SSL to a prespecified remote server.

=back

The following diagram shows a sample usage scenario:

=begin latex

\vbox{ %%% prevent page break for diagram

=end latex

     +-----------+                                  +-----------+
     |           |                                  |           |
     |           |      encrypted data stream       |           |
     |81 stunnel=+==================================+=stunnel 82|
     |           |\                              //||           |
     |-----------| \                     local   /  |-----------|
     |1024       |  \   local            plain- /   |       1024|
     |           |   \  plain-           text   \   |           |
     |           |   /  text             data    \  |           |
     |           |  /   data             stream   \ |           |
     |           ||/    stream                     \_=Client    |
     |    Server=+*-                                |           |
     |           |                                  |           |
     |           |                                  |           |
     +-----------+                                  +-----------+
     TCP ports                                      TCP ports

=begin latex

} %%% prevent page break

=end latex

In this scenario, neither the client nor the server have administrator
privileges, they are running as normal user processes. Also, the
client and server do not support encryption directly.

I<stunnel> makes a secure communication channel available for the
client and server. On the client, I<stunnel> is accepting connections
on TCP port 82. The client connects to this port on the local machine
using normal unencrypted TCP, I<stunnel> accepts the connection, and
opens a new TCP connection to the I<stunnel> server running on the
remote machine. The I<stunnel> instances use cryptographic
certificates to ensure that the data stream has not been intercepted
or tampered with, and then the remote I<stunnel> opens a third TCP
connection to the server, which is again a local unencrypted
connection.

Any data sent by either the client or server is accepted by the
corresponding I<stunnel> instance, encrypted, sent to the other
I<stunnel>, decrypted and finally forwarded to the receiving
program. This way, no modifications are required to the client and
server.

To set up a secure connection compliant with the evaluated
configuration, you MUST start the I<stunnel> server(s) with
administrator rights, and you MUST use a TCP port in the
administrator-reserved range 1-1023 to accept incoming connections.  A
corresponding client which connects to the server MAY be started by
any user, not just administrators.

I<stunnel> MAY also be used by non-administratorive users to receive
encrypted connections on ports in the range 1024-65536. This is
permitted, but it is outside of the scope of the evaluated
configuration and not considered to be a trusted connection.

Any network servers and clients other than the trusted programs
described in this guide (I<stunnel>, I<sshd>, I<vsftpd>, I<postfix>
and I<cupsd>) MUST be run using non-administrator normal user
identities. Programs run from I<stunnel> MUST be switched to a
non-root user ID by using the I<setuid> and I<setgid> parameters in
the F</etc/stunnel/*.conf> configuration files.

It is RECOMMENDED configuring any such servers to accept connections only
from machine-local clients, either by binding only the I<localhost> IP
address 127.0.0.1, or by software filtering inside the
application. This ensures that the only encrypted connections are
possible over the network. Details on how to do this depend on the
software being used and are beyond the scope of this guide.

Please refer to the I<stunnel>(8) and I<openssl>(1) man pages for more
information.

=head3 Creating an externally signed certificate

It is strongly RECOMMENDED that you have your server's certificate signed
by an established Certificate Authority (CA), which acts as a trusted
third party to vouch for the certificate's authenticity for
clients. Please refer to the I<openssl>(1) and I<req>(1) man pages for
instructions on how to generate and use a certificate signing request.

Create the server's private key and a certificate signing request
(CSR) with the following commands:

   touch /etc/stunnel/stunnel.pem

   chmod 400 /etc/stunnel/stunnel.pem

   openssl req -newkey rsa:1024 -nodes \
     -keyout /etc/stunnel/stunnel.pem -out /etc/stunnel/stunnel.csr

You will be prompted for the information that will be contained in the
certificate. Most important is the "Common Name", because the
connecting clients will check if the hostname in the certificate
matches the server they were trying to connect to. If they do not match,
the connection will be refused, to prevent a 'man-in-the-middle'
attack.

Here is a sample interaction:

    Generating a 1024 bit RSA private key
    ..........++++++
    .......++++++
    writing new private key to '/etc/stunnel/stunnel.pem'
    -----
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [PL]:US
    State or Province Name (full name) [Some-State]:TX
    Locality Name (eg, city) []:Austin
    Organization Name (eg, company) [Stunnel Developers Ltd]:Example Inc.
    Organizational Unit Name (eg, section) []:
    Common Name (FQDN of your server) []:www.example.com
    Common Name (default) []:localhost

The file F</etc/stunnel/stunnel.pem> will contain both the certificate
(public key) and also the secret key needed by the server. The secret
key will be used by non-interactive server processes, and cannot be
protected with a passphrase. You MUST protect the secret key from
being read by unauthorized users, to ensure that you are protected
against someone impersonating your server.

Next, send the generated CSR file F</etc/stunnel/stunnel.csr> (I<not>
the private key) to the CA along with whatever authenticating
information they require to verify your identity and your server's
identity. The CA will then generate a signed certificate from the CSR,
using a process analogous to C<openssl req -x509 -in stunnel.csr -key
CA-key.pem -out stunnel.cert>.

When you receive the signed certificate back from the CA, append it to
the file F</etc/stunnel/stunnel.pem> containing the private key using
the following command:

    echo >> /etc/stunnel/stunnel.pem
    cat stunnel.cert >> /etc/stunnel/stunnel.pem

Make sure that the resulting file contains no extra whitespace or
other text in addition to the key and certificate, with one blank line
separating the private key and certificate:

    -----BEGIN RSA PRIVATE KEY-----
    MIICXQIBAAKBgQCzF3ezbZFLjgv1YHNXnBnI8jmeQ5MmkvdNw9XkLnA2ONKQmvPQ
    [...]
    4tjzwTFxPKYvAW3DnXxRAkAvaf1mbc+GTMoAiepXPVfqSpW2Qy5r/wa04d9phD5T
    oUNbDU+ezu0Pana7mmmvg3Mi+BuqwlQ/iU+G/qrG6VGj
    -----END RSA PRIVATE KEY-----

    -----BEGIN CERTIFICATE-----
    MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBXMQswCQYDVQQGEwJQTDET
    [...]
    bIbYKL6Q1kE/vhGmRXcXQrZzkfu8sgJv7JsDpoTpAdUnmvssUY0bchqFo4Hhzkvs
    U/whL2/8RFv5jw==
    -----END CERTIFICATE-----

You MAY distribute the original signed certificate (F<stunnel.cert>
in this example) to clients, it does not contain any confidential
information. I<Never> distribute the file containing the private key,
that is for use by the C<stunnel> server only.

When using externally signed certificates, you MUST use the option
I<CApath> in I<stunnel> client configuration files along with the
setting I<verify=2> or I<verify=3> to enable the clients to verify the
certificate.

=head3 Creating a self-signed certificate

Alternatively, you MAY use a self-signed certificate instead of one
signed by an external CA. This saves some time and effort when first
setting up the server, but each connecting client MUST
manually verify the certificate's validity. Experience shows that most
users will not do the required checking and simply click "OK" for
whatever warning dialogs that are shown, resulting in significantly
reduced security. Self-signed certificates can be appropriate for
controlled environments with a small number of users, but are not
recommended for general production use.

Create a self-signed host certificate with the following commands:

   # create secret key and self-signed certificate
   openssl req -newkey rsa:1024 -nodes \
     -keyout /etc/stunnel/stunnel.pem \
     -new -x509 -sha1 -days 365 \
     -out /etc/stunnel/stunnel.cert

   # set appropriate file permissions
   chmod 400 /etc/stunnel/*.pem
   chmod 444 /etc/stunnel/*.cert
   
   # append copy of certificate to private key
   echo >> /etc/stunnel/stunnel.pem
   cat /etc/stunnel/stunnel.cert >> /etc/stunnel/stunnel.pem

The secret key contained in the F</etc/stunnel/stunnel.pem> file MUST
be kept secret. The key files contain human-readable headers and
footers along with the ASCII-encoded key, and the secret key is marked
with the header "BEGIN RSA PRIVATE KEY".

You MAY distribute the public certificate stored in the
F</etc/stunnel/stunnel.cert> file to clients, and is marked with the
header "BEGIN CERTIFICATE".. Make sure you do not accidentally
distribute the secret key instead.

The client has no independent way to verify the validity of a
self-signed certificate, each client MUST manually verify
and confirm the validity of the certificate.

One method is to give a copy of the self-signed certificate to the
client (using a secure transport mechanism, not e-mail), and import it
into the client directly. The C<stunnel> client uses the I<CAfile>
option for this purpose.

Alternatively, many client programs (not C<stunnel>) can interactively
import the certificate when connecting to the server. The client will
display information about the server's certificate including an MD5
key fingerprint. You MUST compare this fingerprint with the
original fingerprint of the server's certificate.

Run the following command on the server to display the original
certificate's fingerprint:

    openssl x509 -fingerprint -in /etc/stunnel/stunnel.cert

Most clients will store the certificate for future reference, and will
not need to do this verification step on further invocations.

=head3 Activating the tunnel

In the evaluated configuration, you MUST use one of the following cipher suites
as defined in the SSL v3 protocol:

	# Cipher       Proto Key    Authen- Encryption    Message
	#                    exchg  tication              auth code
	#
	RC4-SHA        SSLv3 Kx=RSA Au=RSA  Enc=RC4(128)  Mac=SHA1
	DES-CBC3-SHA   SSLv3 Kx=RSA Au=RSA  Enc=3DES(168) Mac=SHA1
	AES128-SHA     SSLv3 Kx=RSA Au=RSA  Enc=AES(128)  Mac=SHA1
	AES256-SHA     SSLv3 Kx=RSA Au=RSA  Enc=AES(256)  Mac=SHA1

All other cipher suites and the other protocols supported by the
OpenSSL library (TLSv1 and SSLv2) MUST be disabled.

You MUST specify the cipher list and protocol in all I<stunnel> client
and server configuration files:

	ciphers = RC4-SHA:DES-CBC3-SHA:AES128-SHA:AES256-SHA
	options = NO_TLSv1
	options = NO_SSLv2

For a service or tunnel that will only be used temporarily, simply
launch the C<stunnel> program from the command line and specify an
appropriate configuration file. The tunnel will be available for
multiple clients, but will not be started automatically after a
reboot. To shut down the tunnel, search for the command line in the
C<ps ax> process listing, and use the I<kill>(1) command with the PID
shown for the I<stunnel> process.

The RECOMMENDED method is to use two separate configuration files, one
for server definitions (incoming connections use SSL), and one for
client definitions (outgoing connections use SSL). More complex
configurations will require additional configuration files containing
individual service-specific settings. You MUST use the REQUIRED
settings in all I<stunnel> configuration files.

Use the following content for the file F</etc/stunnel/stunnel-server.conf>:

        ### /etc/stunnel/stunnel-server.conf
        #
        # The following settings are REQUIRED for CAPP compliance when used
        # as a server, see ECG. File names MAY be changed as needed.
        cert = /etc/stunnel/stunnel.pem
	ciphers = RC4-SHA:DES-CBC3-SHA:AES128-SHA:AES256-SHA
        options = NO_TLSv1
        options = NO_SSLv2
        #
        # User and group ID MUST NOT be "root", but MAY be changed as needed.
        setuid = nobody
        setgid = nobody
        #
        # The following settings are RECOMMENDED
        debug = 6
        output = /var/log/stunnel-server.log
        pid =
        foreground = yes
        #
        # Individual service definitions follow

Use the following content for the file F</etc/stunnel/stunnel-client.conf>:

        ### /etc/stunnel/stunnel-client.conf
        #
        # The following settings are REQUIRED for CAPP compliance when used
        # as a client, see ECG. File names MAY be changed as needed. You
        # MAY use CApath instead of CAfile for externally signed certificates.
        CAfile = /etc/stunnel/stunnel.cert
	ciphers = RC4-SHA:DES-CBC3-SHA:AES128-SHA:AES256-SHA
        options = NO_TLSv1
        options = NO_SSLv2
        client = yes
        verify = 2
        #
        # User and group ID MUST NOT be "root", but MAY be changed as needed.
        setuid = nobody
        setgid = nobody
        #
        # The following settings are RECOMMENDED
        debug = 6
        output = /var/log/stunnel-client.log
        pid =
        foreground = yes
        #
        # Individual service definitions follow

The RECOMMENDED launch method for I<stunnel>(8) is via the I<init>(8)
process. This requires adding new entries to F</etc/inittab>, the tunnels will be
re-launched automatically whenever they are terminated, as well as
after a reboot. The following are the RECOMMENDED F</etc/inittab> entries:

  ts:3:respawn:/usr/sbin/stunnel /etc/stunnel/stunnel-server.conf
  tc:3:respawn:/usr/sbin/stunnel /etc/stunnel/stunnel-client.conf

Make sure you use the option C<foreground = yes> in the configuration
file when running from init (otherwise C<init> will misinterpret the
backgrounded server as having died and will try to restart it
immediately, causing a loop), and use the C<output> option to redirect
the output to a log file.

=head3 Using the tunnel

If the client program supports SSL encryption, it will be able to
communicate with the I<stunnel> service directly. You MUST
verify and accept the server's certificate if the client cannot
recognize it as valid according to its known certification
authorities.

If the client program does not support SSL directly, you can use
C<stunnel> as a client, or indirectly by setting up a proxy that
allows the client to connect to an unencrypted local TCP port.

B<WARNING:> The C<stunnel> client does I<not> verify the server's
certificate by default. You MUST specify either C<verify = 2> or C<verify = 3> in
the client configuration file to switch on certificate verification.

You MAY also activate client certificate verification in the server's
configuration file, so that the server can verify the client's
identity as well.

As described in the previous section, you MUST specify

	ciphers = RC4-SHA:DES-CBC3-SHA:AES128-SHA:AES256-SHA
        options = NO_TLSv1
        options = NO_SSLv2

in the configuration file to ensure that the cipher selection supported in
the evaluated configuration will be used.

=head3 Example 1: Secure SMTP delivery

Normal SMTP e-mail delivery is not encrypted, but most mail clients
support the enhanced SMTPS protocol that uses SSL encryption. The
protocol itself is unchanged other than being encrypted.

C<stunnel> can easily be used as a proxy to receive SMTPS connections
on the standard port expected by clients (465/tcp), and then forward
the data to the mail server listening on the SMTP port (25/tcp). The
mail server configuration does not need to be modified to support
encryption of incoming mail.

To implement SSL support for incoming mail, add the following service
definition to the F</etc/stunnel/stunnel-server.conf> configuration:

        [inbound_mail]
        accept = 465
        connect = 127.0.0.1:25

=head3 Example 2: Simple web server

The following shell script acts as a simple web server, reading
requests from standard input and writing HTTP/HTML to standard output:

        cat > /usr/local/sbin/webserver_test <<-__EOF__
        #!/bin/sh
        # Simple web server, can be run via stunnel or xinetd
        #
        # read and discard client data
        dd bs=65536 count=1 >/dev/null 2>&1
        #
        # Send HTTP header
        echo -e "HTTP/1.0 200\r"
        echo -e "Content-type: text/html\r"
        echo -e "\r"
        #
        # Send HTML output
        echo "<html>"
        echo "<h1>Test Page</h1>"
        date
        echo "<h2>Memory usage</h2>"
        echo "<pre>"
        free
        echo "</pre>"
        echo "</html>"
        __EOF__

        chmod +x /usr/local/sbin/webserver_test

Add the following entry to the F</etc/stunnel/stunnel-server.conf> configuration to make this service available using the encrypted HTTPS protocol:

        [webserver_test]
        accept = 443
        exec = /usr/local/sbin/webserver_test
        TIMEOUTclose = 0

Then, use a SSL-capable web browser to connect to port 443:

        elinks https://localhost/

=head3 Example 3: system status view

This example shows how to combine I<stunnel> client and server
definitions to implement an encrypted tunnel for applications that do
not themselves support encryption.

First, on the server machine, set up a I<stunnel> server definition
that accepts SSL connections on TCP port 444, and reports memory usage
statistics for the server to connecting clients. Add the following
service definition to the F</etc/stunnel/stunnel-server.conf>
configuration:

        [free]
        accept = 444
        exec = /usr/bin/free
        execargs = free

Then, on the client machine, add the following entry to the
F</etc/stunnel/stunnel-client.conf> configuration, using the server's
IP address instead of "127.0.0.1":

        [free]
        accept  = 81
        connect = 127.0.0.1:444

On the client machine, connect to the local I<stunnel> proxy by
running the following command as a normal user:

        telnet localhost 81

This will open an unencrypted TCP connection to the client's local
port 81, then I<stunnel> builds an encrypted tunnel to the server's
port 444 and transfers the decrypted data (in this case, the "free"
output) back to the client. All unencrypted connections are machine
local, and the data transferred over the network is encrypted.

=head2 The Abstract Machine Testing Utility (AMTU)

The security of the operating system depends on correctly functioning
hardware. For example, the memory subsystem uses hardware support to
ensure that the memory spaces used by different processes are
protected from each other.

The Abstract Machine Testing Utility (AMTU) is distributed as an RPM,
and was installed previously as described in section L<"Add and remove
packages"> "Add and remove packages" of this guide.

To run all supported tests, simply execute the C<amtu> program:

        amtu

A successful run is indicated by the following output:

        Executing Memory Test...
        Memory Test SUCCESS!
        Executing Memory Separation Test...
        Memory Separation Test SUCCESS!
        Executing Network I/O Tests...
        Network I/O Controller Test SUCCESS!
        Executing I/O Controller - Disk Test...
        I/O Controller - Disk Test SUCCESS!
        Executing Supervisor Mode Instructions Test...
        Privileged Instruction Test SUCCESS!

The program will return a nonzero exit code on failure, which MAY be
used to automatically detect failures of the tested systems and take
appropriate action.

Please refer to the I<amtu>(8) man page for more details.

=head2 Setting the system time and date

You MUST verify periodically that the system clock is sufficiently
accurate, otherwise log and audit files will contain misleading
information.  When starting the system, the time and date are copied
from the computer's hardware clock to the kernel's software clock, and
written back to the hardware clock on system shutdown.

All internal dates and times used by the kernel, such as file
modification stamps, use universal time (UTC), and do not depend on
the current time zone settings. Userspace utilities usually adjust
these values to the currently active time zone for display. Note that
text log files will contain ASCII time and date representations in
local time, often without explicitly specifying the time zone.

The I<date>(1) command displays the current time and date, and can be
used by administrators to set the software clock, using the argument
I<mmddHHMMyyyy> to specify the numeric month, day, hour, minute and
year respectively. For example, the following command sets the clock
to May 1st 2004, 1pm in the local time zone:

        date 050113002004

The I<hwclock>(8) can query and modify the hardware clock on supported
platforms, but is not available in virtual environments such as
z/VM. The typical use is to copy the current value of the software
clock to the hardware clock. Note that the hardware clock MAY be
running in either local time or universal time, as indicated by the
I<UTC> setting in the F</etc/sysconfig/clock> file. The following
command sets the hardware clock to the current time using UTC:

        hwclock -u -w

Use the command I<tzselect>(8) to change the default time zone for the
entire system. Note that users MAY individually configure a different
time zone by setting the I<TZ> environment variable appropriately in
their shell profile, such as the F<$HOME/.bashrc> file.

=head2 AppArmor configuration

The evaluated configuration keeps the AppArmor system enabled in a
static configuration, but does not depend on AppArmor for any security
features. You MAY modify the AppArmor configuration, for example to
add additional restrictions, but this is beyond the scope of the CAPP
evaluation.

=head1 Monitoring, Logging & Audit

=head2 Reviewing the system configuration

It is RECOMMENDED that you review the system's configuration at
regular intervals to verify if it still agrees with the evaluated
configuration. This primarily concerns those processes that may run
with 'root' privileges.

The permissions of the device files F</dev/*> MUST NOT be modified.

In particular, review settings in the following files and directories to
ensure that the contents and permissions have not been modified:

        /etc/audit/*
        /etc/cron.allow
        /etc/cron.deny
        /etc/cron.d/*
        /etc/cron.daily/*
        /etc/cron.hourly/*
        /etc/cron.monthly/*
        /etc/cron.weekly/*
        /etc/crontab
        /etc/ftpusers
        /etc/group
        /etc/gshadow
        /etc/hosts
        /etc/init.d/*
        /etc/inittab
        /etc/ld.so.conf
        /etc/login.defs
        /etc/modules.conf
        /etc/pam.d/*
        /etc/passwd
        /etc/securetty
        /etc/security/opasswd
        /etc/security/pam_pwcheck.conf
        /etc/security/pam_unix2.conf
        /etc/shadow
        /etc/ssh/ssh_config
        /etc/ssh/sshd_config
        /etc/stunnel/*
        /etc/sysconfig/*
        /etc/vsftpd.conf
        /etc/xinetd.conf

        /usr/lib/cracklib_dict.*

        /var/log/audit.d/*
        /var/log/faillog
        /var/log/lastlog
        /var/spool/cron/*

Use the command C<lastlog> to detect unusual patterns of logins.

Also verify the output of the following commands (run as 'root'):

        crontab -l
        find / \( -perm -4000 -o -perm -2000 \) -ls
        find / \( -type f -o -type d -o -type b \) -perm -0002 -ls

        find /bin /boot /etc /lib /sbin /usr \
                ! -type l \( ! -uid 0 -o -perm +022 \)

=head2 System logging and accounting

System log messages are stored in the F</var/log/> directory tree in plain text
format, most are logged through the I<syslogd>(8) and I<klogd>(8) programs,
which MAY be configured via the F</etc/syslog.conf> file.

The I<logrotate>(8) utility, launched from F</etc/cron.daily/logrotate>, starts a
fresh log file every week or when they reach a maximum size and automatically
removes or archives old log files. You MAY change the configuration files
F</etc/logrotate.conf> and F</etc/logrotate.d/*> as required.

In addition to the I<syslog> messages, various other log files and status
files are generated in F</var/log> by other programs:

 File           Source
 YaST2          Directory for YaST2 log files
 audit          Directory for audit logs
 boot.msg       Messages from system startup
 lastlog        Last successful log in  (see lastlog(8))
 vsftpd.log     Transaction log of the VSFTP daemon
 localmessages  Written by syslog
 mail           Written by syslog, contains messages from the MTA (postfix)
 messages       Written by syslog, contains messages from su and ssh
 news/          syslog news entries (not used in the evaluated configuration)
 warn           Written by syslog
 wtmp           Written by the PAM susbystem, see who(1)
 xinetd.log     Written by xinetd, logging all connections

Please see I<syslog>(3), I<syslog.conf>(5) and I<syslogd>(8) man pages for
details on syslog configuration.

The I<ps>(1) command can be used to monitor the currently running
processes. Using C<ps faux> will show all currently running processes and
threads.

=head2 Configuring the audit subsystem

The audit subsystem implements a central monitoring solution to keep track of
security relevant events, such as changes and change attempts to security
critical files.

This is accomplished through two separate mechanisms. All system calls are
intercepted, and the kernel writes the parameters and return value to the audit
log for those calls that are marked as security relevant in the filter
configuration. In addition, some trusted programs contain audit-specific code
to write audit trails of the actions they are requested to perform.

Please refer to the I<auditd>(8), I<auditd.conf>(8), and
I<auditctl>(8) man pages for more information.

=head3 Intended usage of the audit subsystem

The Controlled Access Protection Profile (CAPP) specifies the auditing
capabilities that a compliant system must support. The evaluated
configuration described here is based on these requirements.

B<WARNING:> Some of the CAPP requirements may conflict with your
specific requirements for the system. For example, a CAPP-compliant
system MUST disable logins if the audit subsystem is not
working. Please ensure that you are aware of the consequences if you
enable auditing.

CAPP is designed for a multiuser system, with multiple unique users
who maintain both shared and private resources. The auditing features
are intended to support this mode of operation with a reliable trail
of security-relevant operations. It is less useful for a pure
application server with no interactive users.

Please be aware that the auditing subsystem will, when activated,
cause some slowdown for applications on the server. The impact depends
on what the application is doing and how the audit subsystem is
configured. As a rule of thumb, applications that open a large number
of separate files are most affected, and CPU-bound programs should not
be measurably affected. You will need to balance the performance
requirements against your security needs when deciding if and how you
want to use auditing.

=head3 Selecting the events to be audited

You MAY make changes to the set of system calls and events that are to
be audited. CAPP requires that the system has the I<capability> to
audit security relevant events, but it is up to you to choose how you
want to use these capabilities. It is acceptable to turn off system
call auditing completely even in an evaluated configuration, for
example on a pure application server with no interactive users on the
system.

The audit package provides a suggested audit configuration in the
F</usr/share/doc/packages/audit/sample.rules> file. It contains a
suggested setup for a typical multiuser system, all access to security
relevant files is audited, along with other security relevant events
such as system reconfiguration. You MAY copy the sample rules
files to F</etc/audit.rules> and modify the configuration according to
your local requirements, including the option of using an empty audit
rules file to disable auditing if not required.

You MAY selectively disable and enable auditing for specific events or
users as required by modifying the F<audit.rules> file. For example,
you can include and exclude specific users from auditing by adding
filters based on the loginuid, such as the following entry:

	-a exit,always -F auid!=trusteduser -S chown

The audit system also supports filtering on success or failure of
system call operations:

	-F success=1   # for successful syscalls
	-F success!=1  # for unsuccessful syscalls

You MAY configure filesystem watches using the C<-w> option. Note that
filesystem watches are order sensitive if you create multiple watches
for the same inode, for example if creating separate watches for
multiple hard links to a single file. You can filter filesystem
watches, for example to exclude a user ID from being audited:

	-w /etc/shadow -k Secret
	-a watch,never -F auid=trusteduser
	-a exit,possible -S open	

It is RECOMMENDED that you always reconfigure the audit system
by modifying the F</etc/audit.rules> file and then running the
following command to reload the audit rules:

	# as role "auditadm_r"
	auditctl -R /etc/audit.rules

This procedure ensures that the state of the audit system always
matches the content of the F</etc/audit.rules> file. You SHOULD NOT
manually add and remove audit rules and watches on the command line as
those changes are not persistent. 

Note that reloading audit rules involves initially deleting all audit
rules, and for a short time the system will be operating with no or
only a partial set of audit rules. It is RECOMMENDED to make changes
to the audit rules when no users are logged in on the system, for
example by using single user mode or a reboot to activate the changes.

Please refer to the I<auditctl>(8) man page for more details.


=head3 Reading and searching the audit records

Use the I<ausearch>(8) tool to retrieve information
from the audit logs. The information available for retrieval depends
on the active filter configuration. If you modify the filter
configuration, it is RECOMMENDED keeping a datestamped copy of the
applicable configuration with the log files for future reference.

For example:

	# search for events with a specific login UID
	ausearch -ul jdoe

	# search for events by process ID
	ausearch -p 4690

Please refer to the I<ausearch>(8) man page for more details.

Audit messages from the I<pwdutils> user management tools, including
I<useradd> and I<gpasswd>, have the following format:

 type=USER_CHAUTHTOK msg=audit(11.059:63): user pid=33 uid=501 auid=501 
 msg='op=permission denied - account=bin, id=1, by=1000 id=2 exe=gpasswd
      (hostname=?, addr=?, terminal=pts/1 res=success)'

For these specific messages, you MUST refer to the text contained in
the "op=" field to determine the success or failure of the
operation. The "res=success" parenthetical value is always the same
and MUST be ignored.

For some system calls on some platforms, the system call arguments in
the audit record can be slightly different than you may expect from
the program source code due to modifications to the arguments in the C
library or in kernel wrapper functions. For example, the I<mq_open>(3)
glibc library function strips the leading '/' character from the path
argument before passing it to the I<mq_open>(2) system call, leading
to a one character difference in the audit record data. Similarily,
some system calls such as I<semctl>(2), I<getxattr>(2), and
I<mknodat>(2) can have additional internal flags automatically added
to the flag argument. These minor modifications do not change the
security relevant information in the audit record.

Of course, you can use other tools such as plain I<grep>(1) or
scripting languages such as I<awk>(1), I<python>(1) or I<perl>(1) to
further analyze the text audit log file or output generated by the
low-level I<ausearch> tool.

=head3 Starting and stopping the audit subsystem

If the audit daemon is terminated, no audit events are saved until it
is restarted. To avoid lost audit records when you have modified the
filter configuration, you MUST use the command C</etc/init.d/audit
reload> to re-load the filters.

You MUST NOT use the I<KILL> signal (-9) to stop the audit daemon,
doing so would prevent it from cleanly shutting down.

It is RECOMMENDED that you add the kernel parameter C<audit=1> to your
boot loader configuration file to ensure that all processes, including
those launched before the I<auditd> service, are properly attached to
the audit subsystem. Please refer to the documentation of your boot
loader and section L<"Configuring the boot loader"> "Configuring the
boot loader" of this document for more details.

=head3 Storage of audit records

The default audit configuration stores audit records in the
F</var/log/audit/audit.log> file. This is configured in the
I</etc/audit/auditd.conf> file. You MAY change the I<auditd.conf> file
to suit your local requirements.

It is RECOMMENDED that you configure the audit daemon settings
appropriately for your local requirements, for example by changing the
log file retention policy to never delete old audit logs with the
following setting in the F</etc/audit/auditd.conf> file:

	max_log_file_action = KEEP_LOGS

The most important settings concern handling situations where the
audit system is at risk of losing audit information, such as due to
lack of disk space or other error conditions. You MAY choose actions
appropriate for your environment, such as switching to single user
mode (action C<single>) or shutting down the system (action C<halt>)
to prevent auditable actions when the audit records cannot be
stored. 

Halting the system is RECOMMENDED and most certain way to ensure all
user processes are stopped. The following settings are RECOMMENDED in
the F</etc/auditd.conf> file if a fail-secure audit system is
required:

        admin_space_left_action = SINGLE
        disk_full_action = HALT
        disk_error_action = HALT

It is RECOMMENDED that you configure appropriate disk space thresholds
and notification methods to receive an advance warning when the space
for audit records is running low.

It is RECOMMENDED that you use a dedicated partition for the
F</var/log/audit/> directory to ensure that I<auditd> has full control
over the disk space usage with no other processes interfering.

Please refer to the I<auditd.conf>(5) man page for more information
about the storage and handling of audit records.

=head3 Reliability of audit data

You MAY choose an appropriate balance between availability of the
system and secure failure mode in case of audit system malfunctions
based on your local requirements.

You MAY configure the system to cease all processing immediately in
case of critical errors in the audit system. When such an error is
detected, the system will then immediately enter "panic" mode and will
need to be manually rebooted. To use this mode, add the following line
to the I</etc/audit/audit.rules> file:

	-f 2

Please refer to the I<auditctl>(8) man page for more information about
the failure handling modes.

You MAY edit the F</etc/libaudit.conf> file to configure the desired
action for applications that cannot communicate with the audit
system. Please refer to the I<get_auditfail_action>(3) man page for
more information.

I<auditd> writes audit records using the normal Linux filesystem
buffering, which means that information can be lost in a crash because
it has not been written to the physical disk yet. Configuration
options control how I<auditd> handles disk writes and allow the
administrator to choose an appropriate balance between performance and
reliability.

Any applications that read the records while the system is running
will always get the most current data out of the buffer cache, even if
it has not yet been committed to disk, so the buffering settings do
not affect normal operation.

The default setting is C<flush = DATA>, ensuring that record data is
written to disk, but metadata such as the last file time might be
inconsistent.

The highest performance mode is C<flush = none>, but be aware that
this can cause loss of audit records in the event of a system crash.

If you want to ensure that auditd always forces a disk write for each
record, you MAY set the C<flush = SYNC> option in F</etc/audit/auditd.conf>,
but be aware that this will result in significantly reduced
performance and high strain on the disk.

A compromise between crash reliability and performance is to ensure a
disk sync after writing a specific number of records to provide an
upper limit for the number of records lost in a crash. For this, use a
combination of C<flush = INCREMENTAL> and a numeric setting for the
C<freq> parameter, for example:

	flush = INCREMENTAL
	freq = 100

The audit record files are I<not> protected against a malicious
administrator, and are not intended for an environment where the
administrators are not trustworthy.


=head2 System configuration variables in F</etc/sysconfig>

The system uses various files in F</etc/sysconfig> to configure the system.
Most files in this directory tree contain variable definitions in the form of
shell variables that are either read by the rc scripts at system boot time or
are evaluated by other commands at runtime. Note that changes will not
take effect until the affected service is restarted or the system is rebooted.

=head1 Security guidelines for users

=head2 Online Documentation

The system provides a large amount of online documentation, usually in text
format. Use the C<man> program to read entries in the online manual,
for example:

        man ls
        man man

to read information about the C<ls> and C<man> commands respectively.
You can search for keywords in the online manual with the I<apropos>(1)
utility, for example:

        apropos password

When this guide refers to manual pages, it uses the syntax
ENTRY(SECTION), for example  I<ls>(1). Usually you do not need to provide the section
number, but if there are several entries in different sections, you can use
the optional C<-S> switch and pick a specific one.

Some programs provide additional information GNU 'texinfo' format, use the
C<info> program to read it, for example:

        info diff

Additional information, sorted by software package, can be found in the
F</usr/share/doc/*/> directories. Use the I<less>(1) pager to read it,
for example:

        less /usr/share/doc/packages/bash/FAQ

Many programs also support a C<--help>, C<-?> or C<-h> switch you can use to
get a usage summary of supported command-line parameters.

A collection of How-To documents in HTML format can be found under
F</usr/share/doc/howto/en/html> if the optional I<howtoenh> package is
installed.

Please see F</usr/share/doc/howto/en/html/Security-HOWTO> for security
information. The HTML files can be read with the I<w3m> browser.

The SLES documentation is also installed in electronic form.
F</usr/share/doc/packages/sles-inst-*/> contains the installation
guide in PDF format, and F</usr/share/doc/packages/sles-admin-*/> the
administration manual.

Note that this Configuration Guide has precedence over other documents
in case of conflicting recommendations.

=head2 Authentication

You MUST authenticate (prove your identity) before being permitted to
use the system. When the administrator created your user account,
he or she will have assigned a user name and default password, and provided
that information for you along with instructions how to access the system.

Logging in to the system will usually be done using the Secure Shell (SSH)
protocol, alternatively a serial terminal may be available. Use the
C<ssh> command to connect to the system unless instructed otherwise by
the administrator, for example:

        ssh jdoe@172.16.0.1

The I<ssh>(1) manual page provides more information on available options. If
you need to transfer files between systems, use the I<scp>(1) or I<sftp>(1)
tools.

If this is the first time you are connecting to the target system, you will
be prompted if you want to accept the host key. If the administrator
has provided a key fingerprint for comparison, verify that they match,
otherwise type C<yes> to continue. You MUST immediately change your
initially assigned password with the I<passwd>(1) utility.

You MUST NOT under any circumstances attempt to log in from an
insecure device, such as a public terminal or a computer belonging to
a friend. Even if the I<person> owning the computer is trustworthy,
the I<computer> may not be due to having been infected with malicious
code. Always remember that the device you are typing your password
into has the ability to save and re-use your authentication
information, so you are in effect giving the computer you are using
the right to do any and all actions in your name. Insecure handling of
authentication information is the leading cause for exploits of
otherwise secure systems, and SSH can only protect the information
during transit, and offers no protection at all against an insecure
end point.

When you log out from the system and leave the device you have used
for access (such as a terminal or a workstation with terminal
emulation), you MUST ensure that you have not left information on the
screen or within an internal buffer that should not be accessible to
another user. You should be aware that some terminals also store
information not displayed on the terminal (such as passwords, or the
contents of a scrollback buffer). Nevertheless this information may be
extractable by the next user unless the terminal buffer has been
cleared. Safe options include completely shutting down the client
software used for access, powering down a hardware terminal, or
clearing the scrollback buffer by switching among virtual terminals in
addition to clearing the visible screen area.

If you ever forget your password, contact your administrator who
will be able to assign a new password.

You MAY use the I<chsh>(1) and I<chfn>(1) programs to update your
login shell and personal information if necessary. Not all settings
can be changed this way, contact your administrator if you need to
change settings that require additional privileges.

=head2 Password policy

All users, including the administrators, MUST ensure that their
authentication passwords are strong (hard to guess) and handled with
appropriate security precautions. The password policy described here
is designed to satisfy the requirements of the evaluated
configuration. If your organization already has a password policy
defined, your administrator MAY refer you to that policy if it is
equivalently strong.

You MUST change the initial password set by the administrator when you
first log into the system. You MUST select your own password in
accordance with the rules defined here. You MUST also change the
password if the administrator has set a new password, for example if you have
forgotten your password and requested the administrator to reset the
password.

Use the I<passwd>(1) program to change passwords. It will first prompt
you for your old password to confirm your identity, then for the new
password. You will be prompted to enter the new password twice, to catch mistyped
passwords.

The I<passwd>(1) program will automatically perform some checks on
your new password to help ensure that it is not easily guessable, but
you MUST nevertheless follow the requirements in this chapter.

Note that the administrators MUST also ensure that their own passwords
comply with this password policy, even in cases where the automatic
checking is not being done, such as when first installing the system.

=over

=item *

Your password MUST be a minimum of 8 characters in length. More than 8
characters MAY be used (it is RECOMMENDED to use more than 8, best is to
use passphrases), and all characters are significant.

=item *

Use at least one character each from the following sets for passwords:

        Lowercase letters: abcdefghijklmnopqrstuvwxyz
        Uppercase letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ
        Digits:            0123456789
        Punctuation:       !"#$%&'()*+,-./:;<=>?[\]^_`{|}~

=item *

You MUST NOT base the password on a dictionary word, your real name,
login name, or other personal details (such as dates, names of
relatives or pets), or names of real people or fictional
characters.

=item *

Instead of a password, you MAY use a passphrase consisting of multiple
unrelated words (at least three) joined with random punctuation
characters. Such a passphrase MUST have a length of at least 16 characters.

=item *

You MUST NOT use a simple alphabetic string, palindrome or combinations of
adjacent keyboard keys.

=item *

When you choose a new password, it MUST NOT be a simple variation or
permutation of a previously used one.

=item *

You MUST NOT write the password on paper or store it on electronic
devices in unprotected form. Storage in a secure location (such as an
envelope in a safety deposit box, or encrypted storage on an
electronic device) MAY be acceptable, contact your administrator first
to ensure that the protection is strong enough to make password
recovery infeasible for the types of attackers the system is intended
to protect against.

=item *

The password is for you and you only.  A password is like a toothbrush - you
do not want to share it with anybody, even your best friend.  You MUST NOT
disclose your password to anybody else, or permit anybody else to use the
system using your identity.

Note that administrators will never ask you for your password, since
they do not need it even if they are required to modify settings affecting
your user account.

=item *

You MUST NOT use the same password for access to any systems under external
administration, including Internet sites. You MAY however use the same
password for accounts on multiple machines within one administrative unit,
as long as they are all of an equivalent security level and under the
control of the same administrators.

=item *

You MUST inform the administrator and select a new password if you
have reason to believe that your password was accidentally disclosed to a
third party.

=item *

If the system notifies you that your password will expire soon or has
expired, choose a new one as instructed. Contact your administrator
in case of difficulty.

=back

A RECOMMENDED method of generating passwords that fits these criteria while
still being easy to memorize is to base it on letters of words in a sentence
(NOT a famous quotation), including capitalization and punctuation and one
or two variations. Example:

        "Ask not for whom the bell tolls."
        => An4wtbt.

        "Password 'P'9tw;citd' too weak; contained in this document"
        => P'9tw;citd

=head2 Access control for files and directories

Linux is a multiuser operating system. You can control which other users
will be able to read or modify your files by setting the Unix permission
bits and user/group IDs, or (if more precise control is needed) by using
POSIX-style access control lists (ACLs).

Note that the administrators ('root') are able to override these
permissions and access all files on the system. Use of encryption is
RECOMMENDED for additional protection of sensitive data.

The 'umask' setting controls the permissions of newly created files and
directories and specifies the access bits that will be I<removed> from new
objects. Ensure that the setting is appropriate, and never grant write access
to others by default. The umask MUST include at least the 002 bit (no write
access for others), and the RECOMMENDED setting is 027 (read-only and execute
access for the group, no access at all for others).

Do not set up world-writable areas in the filesystem - if you want to share
files in a controlled manner with a fixed group of other users (such as a project
group), please contact your administrator and request the creation of a user
group for that purpose.

Always remember that B<you> are responsible for the security of the data you
create and use. Choose permissions that match the protection goals appropriate
for the content, and that correspond to your organization's security policy.
Access to confidential data MUST be on a need-to-know basis, do not
make data world-readable unless the information is intended to be public.

Whenever you start a program or script, it will execute with your
access rights. This implies that a malicious program would be able to
read and modify all files that you have access to. Never execute any
code that you have received from untrustworthy sources, and do not run
commands that you do not understand. Be aware that manipulations to
the environment a program is run in can also cause security flaws,
such as leaking sensitive information. Do not use the shell variables
LD_LIBRARY_PATH or LD_PRELOAD that modify the shared library
configuration used by dynamically linked programs.

Programs can be configured to run with the access rights of the
program file's owner and/or group instead of the rights of the calling
user. This is the SUID/SGID mechanism, which utilities such as
I<passwd>(1) use to be able to access security-critical files. You
could also create your own SUID/SGID programs via I<chmod>(1), but DO
NOT do that unless you fully understand the security implications -
you would be giving away I<your> access privileges to whoever launches
the SUID program. Please refer to the "Secure Programming HOWTO" in
the unlikely case that you need to create such a program, there you
will find explanations of the many aspects that must be considered,
such as the risk of unintended shell escapes, buffer overflows,
resource exhaustion attacks and many other factors. Note that SUID
root programs MUST NOT be added to the evaluated configuration, the
only permitted use of the SUID bit is for setting non-root user IDs.

Please refer to the I<chmod>(1), I<umask>(2), I<chown>(1), I<chgrp>(1),
I<acl>(5), I<getfacl>(1), and I<setfacl>(1) manual pages for information, or
any of the many available books covering Linux security (cf. Appendix
'Literature'), or ask your system administrator for advice.

=head2 Data import / export

The system comes with various tools to archive data (I<tar>, I<star>,
I<cpio>). If ACLs are used, then only I<star> MUST be used to handle the files
and directories as the other commands do not support ACLs.
The options I<-H=exustar -acl> must be used with I<star>.

Please see the I<star>(1) man page for more information.


=head1 Appendix

=head2 Online Documentation

If there are conflicting recommendations in this guide and in one of
the sources listed here, the Configuration Guide has precedence
concerning the evaluated configuration.

SUSE Linux Enterprise Server Installation Guide,
F</usr/share/doc/manual/sles-preparation-*/>

SUSE Linux Enterprise Server Administrator Guide,
F</usr/share/doc/manual/sles-admin_en/>

David A. Wheeler, "Secure Programming for Linux and Unix HOWTO",
F</usr/share/doc/howto/en/html/Secure-Programs-HOWTO.html>,
F<http://tldp.org/HOWTO/Secure-Programs-HOWTO/>

Kevin Fenzi, Dave Wreski, "Linux Security HOWTO",
F</usr/share/doc/howto/en/html/Security-HOWTO.html>,
F<http://www.linuxsecurity.com/docs/LDP/Security-HOWTO/>

=head2 Literature

Ellen Siever, Stephen Spainhour, Stephen Figgins, & Jessica P. Hekman,
"Linux in a Nutshell, 3rd Edition", O'Reilly 2000, ISBN 0596000251

Simson Garfinkel, Gene Spafford, Alan Schwartz, "Practical Unix & Internet
Security, 3rd Edition", O'Reilly 2003, ISBN 0596003234

Aeleen Frisch, "Essential System Administration, 3rd Edition",
O'Reilly 2002, ISBN 0596003439

Daniel J. Barrett, Richard Silverman, "SSH, The Secure Shell: The Definitive
Guide", O'Reilly 2001, ISBN 0596000111

David N. Blank-Edelman, "Perl for System Administration", O'Reilly 2000, ISBN
1565926099

Shelley Powers, Jerry Peek, Tim O'Reilly, Mike Loukides, "Unix Power Tools, 3rd
Edition", O'Reilly 2002, ISBN 0596003307

W. Richard Stevens, "Advanced Programming in the UNIX(R) Environment",
Addison-Wesley 1992, ISBN 0201563177

Linda Mui, "When You Can't Find Your UNIX System Administrator", O'Reilly 1995,
ISBN 1565921046


=begin latex

\end{document}

=end latex