Draft Department of the Army Linux Security Standard

NOTE: This document is not a product of or for the US Army. None of the information in this document should be construed as official policy.

Executive Summary

Linux is an Operating System (OS) that is based on Unix and can run on many different architectures, from mainframes to embedded systems to clusters. This paper establishes a baseline standard for the secure configuration of Army Linux systems that can connect to Department of Defense (DoD) and Department of the Army (DA) networks. The system configuration guidelines meet or exceed the requirements enumerated in Army Regulation (AR) 25-2, Information Assurance, and applicable DoD directives, guidelines the National Security Agency (NSA), the National Institute of Standards and Technology (NIST), and Business Best Practices (BBP) of the Unix and Linux communities. This document and all of its references are unclassified. All of the government regulations were located on the Internet by searching on Google (http://www.google.com/).

Table of Contents

1. Introduction	1

1.1 Summary	1

1.2 Purpose	1

1.3 Scope	1

1.4 Document Conventions	1

1.4.1 Document Format	1

1.4.2 Key Words	1

2. Hardware	2

2.1 Physical Controls	2

2.1.1 BIOS Settings	2

2.1.2 Dual Boot Systems	3

2.1.3 Boot Loaders	3

2.2 Built in Features	3

2.2.1 Bluetooth	3

2.2.2 Wireless Networking	3

2.2.3 Infrared (IR)	4

2.2.4 Universal Serial Bus (USB)	4

3. Base System Configuration	4

3.1 User Access	4

3.1.1 Password Guidelines	4

3.1.2 Login	5

3.1.3 Root Configuration and Restrictions	6

3.1.4 Lockout Configuration	8

3.2 File System Integrity	9

3.2.1 File Locations	9

3.2.2 Tripwire	9

3.2.3 File Permissions	9

3.2.4 Path	10

4. System Configuration	10

4.1 Ports and Services	10

4.1.1 SSH	10

4.1.2 HTTP	11

4.1.3 FTP	11

4.1.4 SMTP	11

4.1.5 'R' services	11

4.1.6 Telnet	11

4.2 Communications Services	11

4.2.1 Peer-to-Peer (P2P)	11

4.2.2 Instant Messaging (IM)	11

4.2.3 Internet Relay Chat (IRC)	12

4.3 Auditing	12

4.3.1 What to Audit	12

4.3.2 Audit Review	12

4.3.3 Audit Configuration	13

5. Special Considerations	13

5.1 File System Access Control Lists (ACLs)	13

5.2 Data Labeling	13

5.3 Encrypted File Systems	13

5.4 SELinux and the 2.6 kernel tree	14

6. Glossary	15

6.1 Acronyms	15

6.2 Definitions	17

Appendix A: Proposal	19

Appendix B: Progress Report	21

References	22

1. Introduction

1.1 Summary

This document details system configuration guidance for Linux based systems.

1.2 Purpose

The purpose of this document is to give the user, systems administrator, and Information Assurance (IA) personnel guidance on how to set up security on an Army Automated Information System (AIS) running the Linux OS.

1.3 Scope

This document covers both tactical and non-tactical systems that operate either attached to a network or as a stand-alone system. It does not cover systems operating as part of a cluster.

1.4 Document Conventions

System commands, configuration variables are shown using the Courier New font.

1.4.1 Document Format

This document follows the standard document numbering and layout format used in the DoD. Each numbered paragraph that contains one of the keywords listed in the next section is a requirement that can be answered in one of four ways:

meets the standard

meets the standard with an exception

does not meet the standard

does not meet the standard with an exception

This allows the document to be used as a standards document and a checklist to ensure compliance. Any exceptions must be documented and the reason for the exception explained.

1.4.2 Key Words

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 here. To be fully compliant all MUST, REQUIRED, and SHOULD requirements must be implemented. If a requirement designated as a MUST or MUST NOT prevents a valid operational requirement or feature from functioning properly, the MUST or MUST NOT requirement may be downgraded to a SHOULD or SHOULD NOT requirement. Any change of this nature must be documented and approved by the User Representative and the Designated Approving Authority (DAA).

1.4.2.1 MUST

This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification. Any deviation from the requirement must be documented and have an overriding operational reason for not complying.

1.4.2.2 MUST NOT

This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification. Any deviation from the requirement must be documented and have an overriding operational reason for not complying.

1.4.2.3 SHOULD

This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

1.4.2.4 SHOULD NOT

This phrase, or the phrase "NOT RECOMMENDED" means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

1.4.2.5 MAY

This word, or the adjective “OPTIONAL”, means that an item is truly optional. An implementation that does not include a particular option MUST be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. In the same vein an implementation that does include a particular option MUST be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides.)

2. Hardware

The physical hardware that the OS, applications, and data reside on is the first line of defense to protect the system. If an attacker can gain control of the physical device, then it is only a matter of time until the data it contains is compromised. This hardware has capabilities and limitations that must be configured to minimize the potential for compromise.

2.1 Physical Controls

One of the most critical lines of defense is controlling the physical access to the system. If there are no safeguards, any one who gains access to the system may do harm the system. These compromises can lead to the compromise of other systems if they are interconnected.

2.1.1 BIOS Settings

The normal hardware platform for a Linux system is a personal computer (PC). PCs use a Basic Input Output System (BIOS) to provide the instructions needed to bring the system to the point that the operating system can be loaded. If someone can gain physical access to the system, and the BIOS has not been protected, it is possible for someone to boot the system in the single-user mode with the default root shell, and bypass the Identification & Authentication (I&A) process.

The BIOS MUST be password protected to prevent unauthorized users from changing system settings. Only the systems IASO may have the BIOS password.

2.1.2 Dual Boot Systems

A Linux is that it can co-exist with other operating systems, such as the Microsoft Windows family, on the same physical media. In addition to providing a boot manager, all Linux distributions can read Microsoft’s File Allocation Table (FAT and FAT32), and New Technology File System (NTFS) file systems, which allows Linux applications to access the information on these partition types. However, this flexibility comes with risks to the system, and the network the system resides on, if either of the operating systems is not configured securely.

In order to prevent possible compromises or destruction of data, it is RECOMMENDED that only one OS will be installed on an AIS. It is NOT RECOMMENDED that systems give the user the opportunity to interrupt and modify the boot process.

Exceptions will be approved by the IAM, and documented with the IASO. Each additional operating system will meet the provisions of the appropriate Secure Configuration Policy (SCP).

2.1.3 Boot Loaders

There are two standard boot loaders that come with Linux, Linux Loader (LILO) and the Grand Unified Bootloader (GRUB). It is RECOMMENDED that GRUB be used as the bootloader. The bootloader MUST NOT allow the user to select any alternatives.

For GRUB use the 'password' keyword to password protect the boot sequence and prevent users from entering the interactive GRUB shell until the correct password is entered.

For LILO use the keywords 'password' and 'mandatory'. Do not use the 'prompt' keyword. This will require a password be entered before the system will boot. The syntax to use for the password keyword is:

password=""

This will require the user to manually enter the correct password before booting.

2.2 Built in Features

Some manufactures add some features which can make the system easier to use, but are actual or potential security vulnerabilities. These need to be addressed and secured.

2.2.1 Bluetooth

Bluetooth MUST be turned off for all systems. Bluetooth emanations can be detected and read from several hundred feet. There is no valid reason to use Bluetooth in a tactical environment. The threat to the soldiers using the device and the possible compromise of information outweighs any possible benefit offered by Bluetooth.

Ensure Bluetooth is not active by default, and remove the Bluetooth drivers during system installation and configuration.

2.2.2 Wireless Networking

By default wireless networking MUST be disabled. If wireless networking is to be used, all communication links MUST be encrypted. The Wireless Protected Access (WPA) standard with AES encryption SHOULD be used for any wireless networking and is the preferred method.

The Wired Equivalent Privacy (WEP) standard SHOULD NOT be used. If it needs to be used to resolve hardware compatibility issues, 128 bit keys MUST be used and the data MUST be encrypted by the end point systems.

If there is not an operationally compelling reason to use wireless networking it SHOULD NOT be used.

The DAA and the User Representative MUST specifically agree to the use of Wireless Networking before it can be implemented.

2.2.3 Infrared (IR)

Infrared devices MUST be disabled by default. Only if there is a compelling operational reason can IR devices be used. If IR is used the user MUST activate the IR port manually. The IR port MUST automatically deactivate after 5 minutes of inactivity.

2.2.4 Universal Serial Bus (USB)

Newer systems have USB built in and have the ability to be booted from USB devices. It is possible to put a bootable and fully functional Linux system on a 128 Megabit USB storage device known as a thumb drive. It is also possible to copy sensitive data to one of these devices. Justification for having USB active on a system MUST be documented and presented to the DAA. If USB will not be used then the drivers MUST be removed from the system.

3. Base System Configuration

Before any system is deployed it must be correctly configured. The following requirements MUST be used to configure all Linux systems.

3.1 User Access

Only authorized users may use a system. All users MUST be identified, authenticated, and authorized to use any Army IS.

3.1.1 Password Guidelines

Passwords and the individual user are the weakest point in the security system. To lower the risk from poorly selected passwords being used and easily guessed by unauthorized users the following requirements are the standard, as laid out in AR 25-2.

3.1.1.1 Password Length

A password or pass phrase MUST be a minimum of 10-characters. On limited capability systems the passwords MAY be shorter.

3.1.1.2 Password Complexity

The password can be user generated and MUST include at least two of each of the following four types of characters

uppercase letters [A-Z]

lowercase letters [a-z]

numbers [0-9]

special characters, such as !@#$%^&*<>,.{}[]?

Passwords MAY include the space character, but not any other white space characters, such as the tab, new line, or carriage return.

3.1.1.3 Password expiration

Password expiration will be not more than 150 days and MUST be changed every 90 days.

3.1.1.4 Password restrictions

Passwords will not include such references as social security numbers (SSNs), birthdays, Userids, names, slang, military acronyms, call signs, dictionary words, consecutive or repetitive characters, system identification, or names; neither will they be easy to guess (for example, mypassword, abcde12345).

3.1.1.5 Password History

Password history configurations will prevent reutilization of the last 10 passwords when technically possible.

3.1.1.6 Limited Capability Systems

Deployed and tactical systems with limited capabilities (such as hand held and embedded systems) will incorporate password control measures to the extent possible.

3.1.1.7 Default Passwords

All default, system, factory installed, function-key embedded, or maintenance passwords MUST be changed to meet the above requirements.

3.1.1.8 Scripts with Stored Passwords

Automated scripts MAY NOT have embedded passwords.

3.1.1.4 Shadow Passwords

All systems MUST use the shadow password system. The shadow password system removes the encrypted password from the /etc/password file and places it in the /etc/shadow file.

3.1.1.5 DES vs. MD5 encryption

The old standard for Unix password encryption used DES, which limited the password length to 8 characters. Newer systems will also support MD5. Using MD5 will increase the usable length of the password or passphrase to 256 characters. In order to support the currently required password length of 10 characters MD5 MUST be used.

3.1.2 Login

All users MUST be authenticated by the system before the user may interact with the system.

3.1.2.1 Attempts

Unsuccessful attempts to access the system MUST be logged and limited via timeouts.

3.1.2.1.1 Non Tactical Systems

By default Linux doubles the time between each login attempt to slow brute force attacks on the system. In non-tactical situations the user SHOULD be locked out after three unsuccessful login attempts. By default the user SHOULD be locked out until an administrator unlocks the account. However, where the operational need dictates, the lock out MAY be automatically terminated after no less than 30 minutes.

3.1.2.1.2 Tactical Systems

Tactical systems SHOULD NOT have any lock out feature. Unless there is a compelling need to deny access to soldiers in a combat situation access to the system, the unsuccessful attempts SHOULD be logged.

3.1.2.2 Login Warning Banner

All systems MUST display a warning banner when a user logs into the system. The DoD uses a standard warning banner that can be downloaded from the United States Navy Information Security (INFOSEC) Web Information Service (http://infosec.nosc.mil/infosec.html). This banner should resemble the following message:

This is a Department of Defense computer system. This computer system, including all related equipment, networks, and network devices (specifically including Internet access), is provided only for authorized U. S. Government use. DoD computer systems may be monitored for all lawful purposes, including ensuring that their use is authorized, for management of the system, to facilitate protection against unauthorized access, and to verify security procedures, survivability, and operational security. Monitoring includes active attacks by authorized DoD entities to test or verify the security of this system. During monitoring, information may be examined, recorded, copied, and used for authorized purposes. All information, including personal information, placed on or sent over this system may be monitored. Use of this DoD computer system, authorized or unauthorized, constitutes consent to monitoring of this system. Unauthorized use may subject you to criminal prosecution. Evidence of unauthorized use collected during monitoring may be used for administrative, criminal or adverse action. Use of this system constitutes consent to monitoring for these purposes.

3.1.3 Root Configuration and Restrictions

A user with root access has virtually unlimited power on a Unix system. Because of this power access to the root account MUST be tightly controlled.

3.1.3.1 Restrict Root to Console

Anonymous root logins MUST NOT be allowed, except on the system console in emergency situations. At all other times, the administrator should access the system via an unprivileged account and use some authorized mechanism (such as the su command, or the freely-available sudo package) to gain additional privilege. The command ‘sudo’ (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments. If sudo is not distributed with the operating system software, ensure that if it is used, it has been approved by the DAA. To restrict root login to the console type the following commands as the root user:

# cat <<END_FILE >/etc/securetty

tty1

tty2

tty3

tty4

tty5

tty6 END_FILE

# chown root:root /etc/securetty

# chmod 400 /etc/securetty

Attempt to remotely login to the system as root and verify that the operation fails. When correctly set any user who tries to remotely log in to the system must first log in with their user login, and then use the 'sudo' command to execute commands as superuser.

3.1.3.2 Encrypted Root Access

Older protocols such as telnet and rlogin do not encrypt traffic and hence are vulnerable to having passwords and sensitive information captured. All remote administration MUST use encrypted connections. When connecting to a system from another system users MUST use Secure Shell (SSH). Users MAY NOT use telnet or rlogin to conduct root tasks on a system. The current Linux standard is OpenSSH.

3.1.3.3 Use of 'su -' for Root Access

The use of the 'su' to become the root user MUST NOT be allowed. There are several problems with allowing users to become root:

The user needs the root password. The Information Assurance Security Officer (IASO) or Information Assurance Manager (IAM) should be the only users with the root password. The sharing of the root account and password results in a breach of the security requirement for individual I&A and audit requirements. Users are tracked by their Effective User Identification (EUID) and not by their Real User Identification (RUID). Once a user becomes root their EUID is 0 and the audit trail can become obscured.

Invoking 'su -' makes the shell a login shell, which is effectively the same as logging in as root, with all of the same shell, home directory, path, and EUID.

Once logged in as root the user has full control over system. A side effect of this is that a user can change or delete files as root accidentally. This can be a devastating mistake.

Users SHOULD NOT be allowed to invoke 'su' to become root. To support these users other than the IASO or IAM MUST NOT be given the root password. The binary file 'su' SHOULD be moved and replace with a shell script telling the user to use 'sudo' instead.

3.1.3.4 sudo Usage

The 'sudo' command allows only selected users to execute selected commands as root. All commands must be prepended with the command 'sudo'. The command 'sudo' can be configured by user or role in the file /etc/sudo.conf. The user's password (not the root password) is used to invoke 'sudo'.

3.1.3.4.1 sudo versus su

Instead of using 'su' the 'sudo’ command MUST BE used. This negates the need for more than one person from knowing the root password.

The full path to sudo (i.e. '/bin/sudo') SHOULD be used instead of 'sudo' to lower the probability that a fake 'sudo' is invoked. Using 'sudo' instead of 'su' provides several advantages:

The RUID of users is logged for better auditing.

The user has to invoke 'sudo' each time they want to run a command. This is true even if the user writes a shell script to try and bypass the sudo restrictions. This limits the possibility of accidental changing or deletion of files is minimized

The /etc/sudo.conf file will allow users to only run selected commands.

3.1.3.4.2 Configuration of /etc/sudo.conf

The /etc/sudo.conf file is very flexible and the most current documentation should be reviewed when setting up the file. Some items to consider when developing the file are:

Do enumerate exactly which commands the user can invoke.

If appropriate, put time of day limits on the user so they can invoke commands only during their normal duty shift. This is not appropriate in all circumstances.

Do not allow the user to invoke a shell. This example will give the user a bash shell as root.

sudo /bin/bash

Do not give the user access to visudo or directly to the file /etc/sudo.conf. Doing so will allow the user to change the configuration and get greater privileges.

Do not give the user access to 'chown' or 'chmod' because they could access and change the contents of files they are not authorized to access.

3.1.3.5 Root Configuration

Root MUST have:

Use bash as the default shell for compatibility across Linux systems.

User mask (umask) of 077 (as opposed to regular user mask of 037)

The path will not include the current directory.

3.1.4 Lockout Configuration

To increase security, when a user does not interact with the system for a specified period, the user session should either automatically terminate or lock until the user authenticates back into the system.

3.1.4.1 Inactivity Timeout

When users leave their workstations they must log off or lock the keyboard and screen until they reauthenticate. There are certain instances where the screen lockout cannot be used in the tactical environment since it introduces an unacceptable risk of denial of service that will negatively impact the mission. In these instances, the user will either log off or have the person relieving them log into their own account. Screen lock programs can be configured to activate if terminals are idle for a specified period. The IASO and individual users should work together to determine and implement the correct inactivity timeout for their needs.

3.1.4.1.1 Remote

A user who is remotely logged in via FTP, SSH or another service SHOULD be automatically logged out after 10 minutes of inactivity. Each application configures this setting differently so consult the appropriate documentation for setting the timeout.

3.1.4.1.2 X Windows

There is a configuration variable that can be used to terminate sessions after a prescribed time. The .xscreensaver file contains a variable called timeout. If timeout is set for 5 (timeout: 5), the system will automatically log a user off if the mouse or keyboard is inactive for five minutes. The configuration file and variable name may be different in several of the desktop and window managers. Consult the appropriate documentation for proper configuration.

3.1.5 Pluggable Authentication Modules (PAM)

Linux systems and applications can be configured to use Pluggable Authentication Modules to provide authentication services for the overall system and for services running on the system. Multiple modules can be chained together in the following fashion:

auth required pam_deny.so

auth required pam_warn.so

In this example pam_deny will deny access, then pam_warn will send a syslog message to auth.notice.

The system SHOULD implement the follow modules as a minimum:

o pam_warn

o pam_deny

o pam_pwdb

o pam_cracklib

o pam_securetty

o pam_stack

o pam_nologin

o pam_console

o pam_rootok

o pam_time

3.2 File System Integrity

File integrity is a key factor in the protection of Linux systems. System files that must be protected are found in Table 3-1 with the recommended permission settings. The integrity of these files should be checked weekly by taking a system baseline and checking it against the current baseline.

3.2.1 File Locations

Backup/baseline files MUST NOT be located on the same physical device/medium as the primary/online files.

3.2.2 Tripwire

Tripwire is an application that maintains a database of file size location, permissions, and other data to verify file integrity.

3.2.2.1 Use on Non-Tactical Systems

The application MAY be installed on non-tactical systems. If Tripwire is used on a non-tactical system, the system MUST be configured and an initial snapshot of the system made before the system is connected to any networks.

3.2.2.2 Use on Tactical Systems

Tripwire SHOULD NOT be installed on tactical systems due to the high overhead in maintaining the system.

3.2.3 File Permissions

Table 3-1 Critical System Files and File Permissions

FILE/DIRECTORY	PERMISSIONS	DESCRIPTION
/etc/cron.allow	400	Allowed cron access
/etc/cron.deny	400	Denied cron access
/etc/crontab	600	System-wide crontab file
/etc/ftpusers	640	users who cannot FTP
/etc/grub.conf	600	Bootloader config file
/etc/hosts.allow	750	access allow file
/etc/hosts.deny	600	access deny file
/etc/inetd.conf	600	Internet SuperServer configuration file
/etc/init.d	750	Program start-up files on Debian systems
/etc/lilo.conf	600	Bootloader config file
/etc/logrotate.conf	640	Controls rotating of system log files
/etc/pam.d	750	Pam Config Files
/etc/passwd	644	Account Info. File
/etc/rc.d/init.d	750	Program start-up files on Red Hat systems
/etc/securetty	600	TTYs for root logins
/etc/shadow	600	Contains password and password aging info
/etc/shutdown.allow	600	Users allowed ctrl-alt-del
/etc/security	700	System access security policy files
/etc/ssh or /etc/ssh2	750	Secure Shell config files
/etc/sudoers	440	sudo configuration file
/etc/sysctl.conf	400	kernel tunable options on recent Red Hat OSs
/etc/sysconfig	751	System and network config files
/etc/xinetd.conf	600	Internet SuperServer configuration file
/var/log	751	Directory of all log files
/var/log/lastlog	660	Who has logged in before. Use last to view
/var/log/messages	644	System messages
/var/log/wtmp	640	Who is logged in now. Use who to view

3.2.4 Path

The path environmental variable MUST NOT include the current directory, denoted by the use of a single dot ‘.’ in the path statement.

4. System Configuration

The failure to correctly configure systems is the biggest threat to system security. Systems are successfully attacked due to incorrect configuration more often than through application security holes. To prevent this all systems must be configured to minimize exposure to hostile users.

4.1 Ports and Services

Only ports and services required should be available. All insecure ports and services should be turned off and if possible the executable files removed from the system.

4.1.1 SSH

OpenSSH is the preferred implementation of this protocol. It runs on port 22/TCP. The service (sshd) SHOULD be invoked at system startup. SSH protocol version 2 MUST be used, and protocol version 1 MUST NOT be used due to its systemic weaknesses. In addition to Secure Shell the SSH protocol supports Secure Copy (SCP), Secure FTP (SFTP).

4.1.2 HTTP

Normally there is no reason for a web server to be running on the systems covered by this configuration guide. HTTP servers SHOULD NOT be used. It is normally on port 80/TCP or port 443/TCP if SSL/TLS is used. The Apache web server is the standard to be used on these systems and is normally provided by default with the Linux distribution.

Web browsing is allowed and should be fully supported.

4.1.3 FTP

The FTP protocol (ports 21 and 23) and TFTP (port 69) SHOULD NOT be run. They are insecure protocols. If there is a need to run FTP use PureFTP (available at http://www.pureftpd.org/) and configure with chroot() and SSL/TLS support.

4.1.4 SMTP

Simple Mail Transfer Protocol servers SHOULD NOT be running on these systems. All email traffic SHOULD be sent via established, dedicate servers. If an email server is required for operational reasons, Sendmail is the approved SMTP server. An alternative to Sendmail is Postfix (http://www.postfix.org/), which has been developed as a secure replacement for Sendmail.

4.1.5 'R' services

The 'R' services (rlogin, rhost, rexec, etc.) MUST be removed and MUST NOT be run. These services are inherently insecure and there is no valid reason to use them.

4.1.6 Telnet

Telnet passes all traffic, including username and password, in the clear. The Telnet Daemon (telnetd) MUST NOT be run on the system. The service sshd is the preferred replacement for telnetd. The telnet client MAY be used as needed, however, ssh SHOULD be used instead.

4.2 Communications Services

The default configuration of many Linux systems includes tools that enhance the users ability to communicate. In order to prevent the accidental or intentional dissemination of sensitive data, these tools must be used within specific guidelines or removed from the system.

4.2.1 Peer-to-Peer (P2P)

All Peer-to-Peer (P2P) applications SHALL NOT be installed on any systems. No P2P applications are allowed on DoD networks or information systems. There are no expectations to this policy. The threat for covert channels allowing attacks or the removal of sensitive data is too high to allow P2P.

4.2.2 Instant Messaging (IM)

IM applications MAY be used under very tightly controlled situations and only between systems that have identical classification levels (SECRET to SECRET, or UNCLASSIFIED to UNCLASSIFIED). IM MAY NOT be used between systems of different classification levels (i.e. SECRET to TOP SECRET, or UNCLASSIFIED to SECRET). IM MAY NOT be installed on Multilevel Security (MLS) systems. The possibility of accidental release of information is too high to allow use between systems of different classifications. IM MAY NOT be used to discuss classified information.

IM traffic SHOULD NOT be audited or logged without valid legal reason. There are potential legal issues associated with collecting conversations between parties. Consult with legal council before auditing or logging IM traffic.

4.2.3 Internet Relay Chat (IRC)

IRC MAY NOT be installed or used on AIS due to several weaknesses in the protocol and IRC applications that allow malicious users to exploit systems.

If operational considerations dictate that IRC is used and the DAA has accepted the risks involved may be used. However, the same legal considerations on auditing and logging IRC that apply for logging IM traffic.

4.3 Auditing

System activities MUST be logged so problems and issues can be traced. Sometimes the information will help find and correct problems; other times these logs will show security breeches. One of the auditing requirements states that monitoring of user and process activity goes almost to the keystroke level. However later requirements state that gathering too much information is counter productive and should not be done. The amount and what to audit should make sense for the system. Some guidelines for configuring auditing:

Do not collect more than can be reviewed on a daily basis

Collect information that will show actual violations or indicators of possible violations

Do not collect more data than the system can store

Avoid significant load on the system to produce the audit logs

Adjust the amount of auditing to the sensitivity of the system

4.3.1 What to Audit

For all users, including root, the audit system MUST be configured to audit at least the following events:

Logon (unsuccessful and successful) and logout (successful)

Unauthorized access attempts to files (unsuccessful)

Use of privileged commands (unsuccessful and successful)

Application and session initiation (unsuccessful and successful)

Use of print command (unsuccessful and successful)

Discretionary access control permission modification (unsuccessful and successful use of chown/chmod)

Export to media (successful)

System startup and shutdown (unsuccessful and successful)

Files and programs deleted by the user

All system administration actions

All security personnel actions

Invocations of sudo (unsuccessful and successful)

4.3.2 Audit Review

On a daily basis, the IAM or IASO MUST review the audit trails and/or system logs for the following:

Excessive logon attempt failures by single or multiple users

Logons at unusual/non-duty hours

Failed attempts to access restricted system or data files indicating a possible pattern of deliberate browsing

Unusual or unauthorized activity by System Administrators

Command-line activity by a user that should not have that capability

System failures or errors

Unusual or suspicious patterns of activity

4.3.3 Audit Configuration

By default Linux systems have logging configured via syslogd. This daemon is responsible for capturing all logging information generated by non kernel processes. The kernel information is captured by klogd.

4.3.3.1 syslogd Configuration

The default logging daemons are configured via the file /etc/syslog.conf. Correct configuration of the logging system SHOULD include the following entries:

# authentication

auth.* ; authpriv.* /var/log/auth

# kernel messages

kern.* /var/log/kernel

# errors and warning

*.warn; *.err /var/log/messages

4.3.3.2 SNARE

There is an auditing package called SNARE (System iNtrusion Analysis and Reporting Environment) that is available for Linux. This package provides functionality similar to Sun's Basic Security Module (BSM). The SNARE tools provide a range of functionality for detecting intrusions and providing evidence if an intrusion occurs. Systems MAY be configured with SNARE.

5. Special Considerations

Linux has several advanced features that can enhance the security and capabilities of the system. However, not all older applications that are found on Linux systems can support these features.

5.1 File System Access Control Lists (ACLs)

Many, but not all, Linux applications support Access Control Lists, which give greater control over the file permissions than the standard Unix permissions. ACLs SHOULD NOT be used until they are more widely supported by standard Linux applications. Some older applications do not understand ACLs and will overwrite the permissions with standard Unix permissions, hence removing the ACL.

If the Linux system will be running a dedicate Commercial Off-the-Shelf (COTS) or Government Off-the-Shelf (GOTS) application, the ability to support ACLs SHOULD be included during development, and SHOULD be used if appropriate.

5.2 Data Labeling

Unless Mandatory Access Control (MAC) is being implemented, data SHOULD NOT be labeled. If the system is using MAC, data labels MUST be used.

5.3 Encrypted File Systems

For non-tactical mobile systems (laptops and handhelds) encrypting file systems MAY be implemented. Encrypted file systems prevent unauthorized users from accessing data, even if they boot from a separate device.

5.4 SELinux and the 2.6 kernel tree

The default Linux 2.6 kernel tree has support for the NSA produced Security Enhanced Linux. According to the NSA:

Security-enhanced Linux is a research prototype of the Linux® kernel and a number of utilities with enhanced security functionality designed simply to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. The Security-enhanced Linux kernel contains new architectural components originally developed to improve the security of the Flask operating system. These architectural components provide general support for the enforcement of many kinds of mandatory access control policies, including those based on the concepts of Type Enforcement®, Role-based Access Control, and Multi-level Security.

At this time SELinux must still be considered experimental and incomplete. The features incorporated into the 2.6 kernel are also incomplete. SELinux and SELinux enhancements to the 2.6 kernel MUST NOT be used.

6. Glossary

6.1 Acronyms

ACL	Access Control List
AIS	Automated Information System
AR	Army Regulation
BBP	Best Business Practice
BIOS	Basic Input Output System
BSM	Basic Security Module
CA	Certification Authority
COTS	Commercial Off-the-Shelf
DA	Department of the Army
DAA	Designated Approval Authority
DAC	Discretionary Access Control
DISA	Defense Information Systems Agency
DoD	Department of Defense
EUID	Effective User Identification
FAT	File Access Table
FAT32	File Access Table, for 32 bit systems
FTP	File Transfer Protocol
GOTS	Government Off-the-Shelf
GRUB	Grand Unified Bootloader
HTTP	Hyper Text Transfer Protocol
I&A	Identification and Authorization
IA	Information Assurance
IAM	Information Assurance Manager
IASO	Information Assurance Security Officer
IM	Instant Messaging
INFOSEC	Information Systems Security
IP	Internet Protocol
IR	Infrared
IRC	Internet Relay Chat
LILO	Linux Loader
MAC	Mandatory Access Control
MLS	Multilevel Security
NIST	National Institute of Standards and Technology
NSA	National Security Agency
NTFS	New Technology File System
OpenSSH	Open Secure Shell
OS	Operating System
P2P	Peer to Peer
PAM	Pluggable Authentication Modules
PC	Personal Computer
RUID	Real User Identification
SCP	Secure Copy or Secure Configuration Policy
SFTP	Secure File Transfer Protocol
SMTP	Simple Mail Transfer Protocol
SSH	Secure Shell
TCP	Transport Control Protocol
TCP/IP	Transmission Control Protocol/Internet Protocol
USB	Universal Serial Bus
WEP	Wired Equivalent Protection
WPA	Wireless Protected Access

6.2 Definitions

Accreditation	A formal declaration by the designated approving authority (DAA) that the automated information system (AIS) is approved to operate in a particular security mode using a prescribed set of safeguards. Accreditation is the official management authorization for operation of an AIS and is based on the certification process as well as other management considerations. The accreditation statement affixes security responsibility with the DAA and shows that due care has been taken for security.
Audit Trail	A chronological record of system activities that is sufficient to enable the reconstruction, reviewing, and examination of the sequence of environments and activities surrounding or leading to an operation, a procedure, or an event in a transaction from its inception to final results.
Authentication	The process of reliably (1) verifying the identity of a user, device, or other entity in a computer system, often as a prerequisite to allowing access to resources in a system; or (2) verifying the integrity of data that have been stored, transmitted, or otherwise exposed to possible unauthorized modification.
Authorization	The granting of access rights to a user, program, or process.
Automated Information System (AIS)	An assembly of computer hardware, software, and/or firmware configured to collect, create, communicate, compute, disseminate, process, store, and/or control data or information.
Certification	The comprehensive evaluation of the technical and nontechnical security features of an AIS and other safeguards, made in support of the accreditation process, that establishes the extent to which a particular design and implementation meet a specified set of security requirements.
Certification Authority (CA)	The official responsible for performing the comprehensive evaluation of the technical and nontechnical security features of an IT system and other safeguards, made in support of the accreditation process, to establish the extent that a particular design and implementation meet a set of specified security requirements.
Classification	Secret, Unclassified Sensitive, Unclassified, etc.
Designated Approving Authority (DAA or Accreditor)	Official with the authority to formally assume the responsibility for operating a system or network at an acceptable level of risk.
Discretionary Access Control (DAC)	A means of restricting access to objects based on the identity and need-to-know of the user, process, and/or groups to which they belong. The controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject. Compare mandatory access control.
Identification	An entity's (person's or computer's) name
Integrity	Verifying that a message has not been modified.
Label	Classification tag bound to electronic data or information to 'seal' it.
Mandatory Access Control (MAC)	A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity. Compare discretionary access control.
Marking	Classification tag placed on human-readable information
Multilevel Security (MLS)	An MLS system is a system containing information with different security classifications that simultaneously permits access by users with different security clearances and needs to know. This system prevents users from obtaining access to information for which they lack authorization.
User	Person or process authorized to access an IT system.

References

Garfinkle, S., Spafford, G., and Schwartz, A. (2003). Practical Unix and Internet Security (3rd ed). Sebastapol, CA: O'Reilly and Associates.

Fenzi, K., and Wreski, D. (2004), Linux Security HOWTO (version 2.3). http://www.linux.org/docs/ldp/howto/Security-HOWTO/index.html

Defense Information Systems Agency (DISA) (2003), UNIX SECURITY TECHNICAL IMPLEMENTATION GUIDE (Version 4, Release 4)(Unclassified). Washington, D.C.: DISA

DISA (2004), UNIX Security Checklist (Version 4, Release 4)(Unclassified). Washington, D.C.: DISA

United States Army (2003), Army Regulation 25-2, Information Assurance (Unclassified). Washington, D.C.: Department of the Army

Draft Department of the Army Linux Security Standard

18

Department of the Army Linux Security Standard

Department of the Army Linux Security Standard

andy

2004-06-19T12:53:00