Security Guide

Controlled Access Protection Profile and Evaluation Assurance Level 4+

In AIX 5.2, system administrators can install a system with the Controlled Access Protection Profile (CAPP) and Evaluation Assurance Level 4+ (EAL4+) option during a CD-ROM base operating system (BOS) installation. A system with this option has restrictions on the software that is installed during BOS installation, plus network access is restricted.

This section discusses the following topics:

CAPP/EAL4+ Compliant System Overview

A CAPP system is a system that has been designed and configured to meet the Controlled Access Protection Profile (CAPP) for security evaluation according to the Common Criteria. The CAPP specifies the functional requirements for the system, similar to the old TCSEC C2 standard (also known as the Orange Book).

A Common Criteria (CC) Evaluated System is a system that has been evaluated according to the Common Criteria, an ISO standard (ISO 15408) for the assurance evaluation of IT products. AIX 5.2 contains the technology to meet the requirements of the CAPP and CC assurance level EAL4+. The system configuration that meets these requirements is referred to as a CAPP/EAL4+ system in this guide.

If a system is evaluated according to the CC, the CC evaluation is valid only for a specific system configuration (hardware and software). Changing the relevant security configuration results in a nonevaluated system. This does not necessarily mean that the security of the system will be reduced, but only indicates that the system is no longer in a certified configuration. This chapter will explain the constraints of a system that must meet the CAPP and the requirements of a CC evaluation. Neither the CAPP nor the CC cover all possible security configuration options of AIX 5.2. Some features, such as IPsec or custom-password checking modules, are not included, but can be used to enhance the security of the system.

The AIX 5.2 CAPP/EAL4+ system includes the base operating system on 64-bit POWER3 and POWER4 Processors with the following:

Logical Volume Manager (LVM) and the enhanced journaled file system (JFS2)
The X-Windows system with the CDE GUI
Basic Internet Protocol version 4 (IPv4) network functions (Telnet, FTP, rlogin, rsh/rcp)
Network File System (NFS)

A CAPP/EAL4+ system is considered to be in a secured state, if the following conditions apply:

If auditing is configured and the system is in multi-user mode, then auditing must be operational.
The system accepts user logins and services network requests.
For a distributed system, the administrative databases are NFS-mounted from the master server.

For the latest information on CAPP/EAL4+, refer to the AIX 5.2 Release Notes.

Installing a CAPP/EAL4+ System

To set the CAPP/EAL4+ option during a BOS installation, do the following:

In the Installation and Settings screen, select More Options.
In the More Options screen, type the number corresponding to the Yes or No choice for Enable CAPP and EAL4+ Technology. The default is no.

The Enable CAPP and EAL4+ Technology option is available only under the following conditions:

The installation method is set to new and complete overwrite installation.
The English language is selected.
The 64-bit kernel is enabled.
The enhanced journaled file system (JFS2) is enabled.

When the Enable CAPP and EAL4+ Technology option is set to yes, the Trusted Computing Base option is also set to yes, and the only valid Desktop choices are NONE or CDE.

If you are performing a nonprompted installation using a customized bosinst.data file, the INSTALL_TYPE field must be set to CC_EVAL and the following fields must be set as follows:

INSTALL_TYPE = CC_EVAL
INSTALL_METHOD = overwrite
TCB = yes
DESKTOP = NONE or CDE

A CAPP/EAL4+ system can also be installed using the Network Installation Management (NIM) environment. To install a CAPP/EAL4+ client, the NIM master must be a CAPP/EAL4+ system. Although both systems can be on the building network, CAPP/EAL4+ systems can only communicate with other CAPP/EAL4+ systems. To install a CAPP/EAL4+ client, a bosinst_data resource must be defined and the fields edited, as shown above.

CAPP/EAL4+ Software Bundle

When the CAPP/EAL4+ option is selected, the contents of the /usr/sys/inst.data/sys_bundles/CC_EVAL.BOS.autoi installation bundle are installed.

You can optionally select to install the graphics software bundle and the documentation services software bundle with the CAPP/EAL4+ option selected. If you select the Graphics Software option with the CAPP/EAL4+ option, the contents of the /usr/sys/inst.data/sys_bundles/CC_EVAL.Graphics.bnd software bundle are installed. If you select the Documentation Services Software option with the CAPP/EAL4+ option, the contents of the /usr/sys/inst.data/sys_bundles/CC_EVAL.DocServices.bnd software bundle are installed.

After the Licensed Program Products (LPPs) have been installed, the system changes the default configuration to comply with the CAPP/EAL4+ requirements. The following changes are made to the default configuration:

Remove /dev/echo from the /etc/pse.conf file.
Instantiate streams devices.
Allow only root to access removable media.
Remove non-CC entries from the inetd.conf file.
Change various file permissions.
Register symlinks in the sysck.cfg file.
Register devices in the sysck.cfg file.
Set default user and port attributes.
Configure the doc_search application for browser use.
Remove httpdlite from the inittab file.
Remove writesrv from the inittab file.
Remove mkatmpvc from the inittab file.
Remove atmsvcd from the inittab file.
Disable snmpd in the /etc/rc.tcpip file.
Disable hostmibd in the /etc/rc.tcpip file.
Disable snmpmibd in the /etc/rc.tcpip file.
Disable aixmibd in the /etc/rc.tcpip file.
Disable muxatmd in the /etc/rc.tcpip file.
NFS port (2049) is a privileged port.
Add missing events to the /etc/security/audit/events file.
Ensure that the loopback interface is running.
Create synonyms for /dev/console.
Enforce default X-server connection permissions.
Change the /var/docsearch directory so that all files are world-readable.
Add ODM stanzas to set the console permissions.
Set permissions on BSD-style ptys to 000.
Disable .netrc files.
Add patch directory processing.

Physical Environment for a CAPP/EAL4+ System

The CAPP/EAL4+ system has specific requirements for the environment in which it is run. The requirements are as follows:

Physical access to the systems must be restricted so that only authorized administrators can use the system consoles.
The Service Processor is not connected to a modem.
Physical access to the terminals is restricted to authorized users.
The physical network is secure against eavesdropping and spoofing. When communicating over insecure lines, additional security measures, such as encryption are needed.
Communication with other systems that are not AIX 5.2 CAPP/EAL4+ systems, or are not under the same management control, is not permitted.
Only IPv4 is to be used when communicating with other CAPP/EAL4+ systems, IPv6 has not been evaluated.
Users should not be allowed to change the system time.

Organizational Environment for a CAPP/EAL4+ System

The following procedural and organizational requirements must be met for a CAPP/EAL4+ system:

Only users authorized to work with the information on the systems are granted user IDs on the system.
Users must use high-quality passwords (as random as possible and not affiliated with the user or the organization). For information about setting up password rules, see Passwords.
Users must not disclose their passwords to others.
Administrators must have sufficient knowledge to manage security critical systems.
Administrators must work in accordance with the guidance provided by the system documentation.
Administrators must log in with their personal ID and use su - to switch to superuser mode for administration.
Passwords generated for system users by administrators must be transmitted securely to the users.
Those who are responsible for the system must establish and implement the necessary procedures for the secure operation of the systems.
Administrators must ensure that the access to security-critical system resources is protected by appropriate settings of permission bits and ACLs.
The physical network must be approved by the organization to carry the most sensitive data held by the systems.
Maintenance procedures must include regular diagnostics of the systems.
The administrators must have procedures in place that ensure a secure operation and recovery after a system failure.
The LIBPATH environment variable should not be changed, because this might result in a trusted process loading an untrusted library.
Wiretapping and trace software (tcpdump, trace) must not be used on an operational system.
Anonymous protocols such as HTTP may only be used for public information (for example, the online documentation).
Only TCP-based NFS can be used on a CAPP/EAL4+ system.
Access to removable media is not to be given to users. The device files are to be protected by appropriate permission bits or ACLs.
Only root authority is used when administering AIX. All the role-based and group-based administration-delegation features, as well as the privilege mechanism of AIX, are not included in the CAPP/EAL4+ compliance.

System Configuration for a CAPP/EAL4+ System

This section provides information about the configuration of the subsystems involved in a CAPP/EAL4+ system.

Administration

Administrators must log in with their personal user account and use the su command to become the root user for the administration of the system. To effectively prevent guessing the root account's password, only authorized administrators should be allowed to use the su command on the root account. To ensure this, do the following:

Add an entry to the root stanza of the /etc/security/user file as follows:
```
root:
		admin = true
		.
		.
		.
		sugroups = SUADMIN
```
A group must be defined in the /etc/group file containing only the user IDs of authorized administrators as follows:
```
system:!:0:root,paul
staff:!:1:invscout,julie
bin:!:2:root,bin
.
.
.
SUADMIN:!:13:paul
```

Administrators must also adhere to the following procedures:

Establish and implement procedures to ensure that the hardware, software and firmware components that comprise the distributed system are distributed, installed, and configured in a secure manner.
Ensure that the system is configured so that only an administrator can introduce new trusted software into the system.
Implement procedures to ensure that users clear the screen before logging off of serial login devices (for example, IBM 3151 terminals).

User and Port Configuration

AIX configuration options for users and ports must be set to satisfy the requirements of the evaluation. The actual requirement is that the probability of correctly guessing a password should be at least 1 in 1,000,000, and the probability of correctly guessing a password with repeated attempts in one minute should be at least 1 in 100,000.

The recommended values for the /etc/security/user file are the following:

default:
		admin = false
		login = true
		su = true
		daemon = true
		rlogin = true
		sugroups = ALL
		admgroups =
		ttys = ALL
		auth1 = SYSTEM
		auth2 = NONE
		tpath = nosak
		umask = 077
		expires = 0
		SYSTEM = "compat"
		logintimes =
		pwdwarntime = 5
		account_locked = false
		loginretries = 3
		histexpire = 52
		histsize = 20
		minage = 0
		maxage = 8
		maxexpired = 1
		minalpha = 2
		minother = 2
		minlen = 8
		mindiff = 4
		maxrepeats = 2
		dictionlist = /usr/share/dict/words
		pwdchecks =
		dce_export = false

root:
		rlogin = false
		login = false

The default settings in the /etc/security/user file should not be overwritten by specific settings for single users.

Note

Setting login = false in the root stanza prevents direct root login. Only user accounts that have su privileges for the root account will be able to log in as the root account. If a Denial of Service attack is launched against the system that sends incorrect passwords to the user accounts, it could lock all the user accounts. This attack might prevent any user (including administrative users) from logging into the system. Once a user's account is locked, the user will not be able to log in until the system administrator resets the user's unsuccessful_login_count attribute in the /etc/security/lastlog file to be less than the value of the loginretries user attribute. If all the administrative accounts become locked, you might need to reboot the system into maintenance mode and run the chsec command. For more information on using the chsec command, see User Account Control.

The recommended values for the /etc/security/login.cfg file are the following:

default:         
		sak_enabled = false         
		logintimes =         
		logindisable = 4         
		logininterval = 60         
		loginreenable = 30         
		logindelay = 5

Resource Limits

When setting resource limits in the /etc/security/limits file, make sure that the limits correspond to the needs of the processes on the system. In particular, the stack and rss sizes should never be set to unlimited. An unlimited stack might overwrite other segments of the running process, and an unlimited rss size allows a process to use all real memory, therefore creating resource problems for other processes. The stack_hard and rss_hard sizes should be limited as well.

Audit Subsystem

The following procedures help protect the audit subsystem:

Configure the audit subsystem to record all the relevent security activities of the users. To ensure that the file space needed for auditing is available and is not impaired by other consumers of file system space, set up a dedicated file system for audit data.
Protect audit records (such as audit trails, bin files, and all other data stored in /audit) from non-root users.
For the CAPP/EAL4+ system, bin mode auditing must be set up when the audit subsystem is used. For information about how to set up the audit subsystem, refer to Setting Up Auditing.
At least 20 percent of the available disk space in a system should be dedicated to the audit trail.
If auditing is enabled, the binmode parameter in the start stanza in /etc/security/audit/config should be set to panic. The freespace parameter in the bin stanza should be configured at minimum to a value that equals 25 percent of the disk space dedicated to the storage of the audit trails. The bytethreshold and binsize parameters should each be set to 65536 bytes.
Copy audit records from the system to permanent storage for archival.

Network Configuration

Network configuration must use Discretionary Access Control for Internet Ports (DACinet) to make sure that the X protocol (X11) and NFS cannot be used anonymously. For more information on the dacinet command, see User Based TCP Port Access Control with Discretionary Access Control for Internet Ports.

The dacinet command prevents the following conditions:

A user from taking over another user's desktop with X11.
A user on a client from forging requests to an NFS server that would permit the user to become root. Normally, a user accesses a remote NFS server by making requests to the Logical File System on the local host, which then makes the request (as root) to the remote server. Setting an ACL for root only and not permitting this port to be bypassed ensures that the user cannot send direct protocol requests to an NFS server.

System Services

The following table shows the standard system services running on a CAPP/EAL4+ system (if there is no graphics card).

Table 1. Standard System Services
UID	Command	Description
root	/init	The Init process
root	/usr/sbin/syncd 60	File system sync daemon
root	/usr/sbin/srcmstr	SRC master daemon
root	/usr/sbin/cron	CRON facility with AT support
root	/usr/ccs/bin/shlap64	Shared Library Support Daemon
root	/usr/sbin/syslogd	Syslog daemon
root	/usr/lib/errdemon	AIX error log daemon
root	/usr/sbin/getty /dev/console	getty / TSM
root	/usr/sbin/portmap	Portmapper for NFS and CDE
root	/usr/sbin/biod 6	NFS Client
root	/usr/sbin/rpc.lockd	NFS lock daemon
daemon	/usr/sbin/rpc.statd	NFS stat daemon
root	/usr/sbin/rpc.mountd	NFS mount daemon
root	/usr/sbin/nfsd	NFS server daemon
root	/usr/sbin/inetd	Inetd master daemon
root	/usr/sbin/uprintfd	Kernel print daemon
root	/usr/sbin/qdaemon	Queuing daemon
root	/usr/lpp/diagnostics/bin/diagd	Diagnostics

Running a CAPP/EAL4+ Distributed System

To run a distributed system that is CAPP/EAL4+ compliant, all users must have identical user IDs on all systems. Although this can be achieved with NIS, the result is not secure enough for a CAPP/EAL4+ system. This section describes a distributed setup that ensures that the user IDs are identical on all systems that are CAPP/EAL4+ compliant.

The master system stores the identification and authentication data (user and group configuration) for the whole distributed system. All other systems use NFS to mount this data. NFS is protected by DACinet so that only the administrators can access the NFS ports on the master.

Authentication data can be changed by any administrator by using tools, such as SMIT, on any system. Authentication data is physically changed on the master.

All shared identification and authentication data comes from the /etc/data.shared directory. The regular identification and authentication files are replaced by symbolic links into the /etc/data.shared directory.

Shared Files in the Distributed System

The following files are shared in the distributed system. Typically, they come from the /etc/security directory.

Table 2. Shared Files in the Distributed System
File	Description
/etc/security/.ids	The next available user and group ID
/etc/security/.profile	The default .profile file for new users
/etc/security/audit/bincmds	Bin-mode auditing commands for this host
/etc/security/audit/config	Local audit configuration
/etc/security/audit/events	List of audit events and formats
/etc/security/audit/objects	List of audited objects on this host
/etc/security/audit/streamcmds	Stream-mode auditing commands for this host
/etc/security/environ	Per-user environmental variables
/etc/group	The /etc/group file
/etc/passwd	The /etc/passwd file
/etc/security/group	Extended group information from the /etc/security/group file
/etc/hosts	The /etc/hosts file
/etc/security/limits	Per-user resource limits
/etc/security/passwd	Per-user passwords
/etc/security/user	Per-user and default user attributes
/etc/security/priv	Ports that are to be designated as privileged when the system starts are listed in the /etc/security/priv file
/etc/security/services	Ports listed in the /etc/security/services file are considered exempt from ACL checks
/etc/security/acl	The /etc/security/acl file stores system-wide ACL definitions for protected services that will be reactivated at the next system boot by the /etc/rc.tcpip file.

Nonshared Files in the Distributed System

The following files in the /etc/security directory are not to be shared in the distributed system, but are to remain host-specific:

Table 3. Nonshared files in the Distributed System
File	Description
/etc/security/failedlogin	Log file for failed logins per host
/etc/security/lastlog	Per-user information about the last successful and unsuccessful logins on this host
/etc/security/portlog	Per-port information for locked ports on this host
/etc/security/login.cfg	Host-specific login characteristics for trusted path, login shells, and other login-related information

The automatically generated backup files of the shared files are also nonshared. Backup files have the same name as the original file, but have a lowercase letter o prepended.

Setting up the Distributed System (The Master System)

On the master, a new logical volume is created that holds the file system for the identification and authentication data. The logical volume is named /dev/hd10sec and it is mounted on the master system as /etc/data.master. To generate the necessary changes on the master system, run the mkCCadmin command with the IP address and host name of the master, as follows:

mkCCadmin -m -a ipaddress hostname

Setting up the Distributed System (All Systems)

All data that is to be shared is moved to the /etc/data.shared directory. At startup all systems will mount the master's /etc/data.master directory over the /etc/data.shared directory. The master itself uses a loopback mount.

Client systems are set up by running the following:

mkCCadmin -a ipaddress hostname

To change the client to use a different master, use the chCCadmin command.

After a system has been integrated into the distributed identification and authentication system, the following additional inittab entries are generated:

isCChost: Initializes the system to CAPP/EAL4+ mode.
rcCC: This clears all DACinet ACLs and opens only the ports needed for the portmapper and NFS. It then mounts the shared directory.
rcdacinet: This loads additional DACinet ACLs that the administrator might have defined.

Consider the following

When running the distributed system,

Administrators must make sure that the shared data is mounted before changing shared configuration files to ensure that the shared data is seen on all systems.
Changing the root password is the only administrative action that is permitted while the shared directory is not mounted.

Using the DACinet Feature for User and Port Based Network Access Control

The DACinet feature can be used to restrict the access of users to TCP ports. For more information about DACinet, see User Based TCP Port Access Control with Discretionary Access Control for Internet Ports. For example, when using DACinet to restrict access to port TCP/25 inbound to root only with the DACinet feature, only root users from CAPP/EAL4+ compliant hosts can access this port. This situation limits the possibilities of regular users spoofing e-mail by using telnet to connect to port TCP/25 on the victim.

To activate the ACLs for TCP connections at boot time, the /etc/rc.dacinet script is run from /etc/inittab. It will read the definitions in the /etc/security/acl file and load ACLs into the kernel. Ports which should not be protected by ACLs should be listed in /etc/security/services. This file uses the same format as the /etc/services file.

Assuming a subnet of 10.1.1.0/24 for all the connected systems, the ACL entries to restrict access to the root user only for X (TCP/6000) in /etc/security/acl would be as follows:

      6000    10.1.1.0/0xFFFFFF00 u:root

Installing Additional Software on a CAPP/EAL4+ Compliant System

The administrator can install additional software on the CAPP/EAL4+ compliant system. If the software is not run by the root user or with root user privileges, this will not invalidate the CAPP/EAL4+ compliance. Typical examples include office applications that are run only by regular users and have no SUID components.

Additionally, installed software that runs with root user privileges, invalidates the CAPP/EAL4+ compliance. This means, for example, drivers for the older JFS should not be installed, as they are running in kernel mode. Additional daemons that are run as root (for example, an SNMP daemon) also invalidates the CAPP/EAL4+ compliance.

A CAPP/EAL4+ compliant system is rarely used in the evaluated configuration, especially in a commercial environment. Typically, additional services are needed, so that the production system is based on an evaluated system, but does not comply with the exact specification of the evaluated system.