Guide to the Secure Configuration of WRLinux

This guide presents a catalog of security-relevant configuration settings for WRLinux. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the config_item="scap-security-guide" package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a italics="catalog, not a checklist," and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF italics="Profiles", which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for WRLinux, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile ID(default)

CPE Platforms

  • cpe:/o:windriver:wrlinux:8

Revision History

Current version: 0.1.39

  • draft (as of 2021-12-31)

Table of Contents

  1. Remediation functions used by the SCAP Security Guide Project
  2. Services
    1. Audit Settings
    2. Ftp Settings
    3. Ntp Settings
    4. Snmp Settings
    5. Cron and At Daemons
    6. Base Services
    7. Nfs Settings
    8. ssh Settings
    9. Xorg Settings
  3. System Settings
    1. Auditing Settings
    2. Logging Settings
    3. General System Wide Configuration Settings
    4. SE Linux Settings
    5. Account and Access Control
    6. Installing and Maintaining Software
    7. File Permissions and Masks

Checklist

Group   Guide to the Secure Configuration of WRLinux
Group   Remediation functions used by the SCAP Security Guide Project

[ref]   XCCDF form of the various remediation functions as used by remediation scripts from the SCAP Security Guide Project.

Group   Services

[ref]   The best protection against vulnerable software is running less software. This section describes how to review the software which WRLinux installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default WRLinux system and provides guidance about which ones can be safely disabled.

WRLinux provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building WRLinux systems, it is highly recommended to select the minimal packages and then build up the system from there.

Group   Audit Settings

[ref]  

Group   Ftp Settings

[ref]  

Group   Ntp Settings

[ref]  

Group   Snmp Settings

[ref]  

Group   Cron and At Daemons

[ref]   The cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively.

Group   Base Services

[ref]   This section addresses the base services that are installed on a Wind River Linux 8 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required.

Group   Nfs Settings

[ref]  

Group   ssh Settings

[ref]  

Group   Xorg Settings

[ref]  

Group   System Settings

[ref]   Contains rules that check correct system settings.

Group   Auditing Settings

[ref]  

Group   Logging Settings

[ref]  

Group   General System Wide Configuration Settings

[ref]   The following sections contain information on various security-relevant configuration settings that in particular way modify the behaviour of the system as a whole.

Group   SE Linux Settings

[ref]  

Group   Account and Access Control

[ref]   In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under WRLinux.

Group   Protect Accounts by Restricting Password-Based Login

[ref]   Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the /etc/passwd and /etc/shadow files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary.

Group   Set Password Expiration Parameters

[ref]   The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information.

Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.

The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.

For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command:

# chage -M 180 -m 7 -W 7 USER

Group   Restrict Root Logins

[ref]   Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins.
The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Furthermore, /dev/hvc* represent virtio-serial consoles, /dev/hvsi* IBM pSeries serial consoles, and finally /dev/xvc0 Xen virtual console. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH.

Group   Account expiration Settings
Group   Proper Storage and Existence of Password Hashes

[ref]   By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration.

Group   Banners Settings

[ref]  

Group   Physical Settings

[ref]  

Group   pam Settings

[ref]  

Group   Secure Session Configuration Files for Login Accounts

[ref]   When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.

Group   Ensure that No Dangerous Directories Exist in Root's Path

[ref]   The active path of the root account can be obtained by starting a new root shell and running:

$ sudo echo $PATH
This will produce a colon-separated list of directories in the path.

Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user.

It is a good practice for administrators to always execute privileged commands by typing the full path to the command.

Group   Ensure that Users Have Sensible Umask Values

[ref]   The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

Group   Installing and Maintaining Software

[ref]   The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

Group   Integrity Settings

[ref]  

Group   Gnome Settings

[ref]  

Group   Updating Settings

[ref]  

Group   File Permissions and Masks

[ref]   Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.

Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn.

The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Red Hat Enterprise Linux 7 installations:

$ mount -t xfs | awk '{print $3}'
For any systems that use a different local filesystem type, modify this command as appropriate.

Group   Verify Permissions on Important Files and Directories

[ref]   Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.

Group   Verify Permissions on Files with Local Account Information and Credentials
Group   Verify File Permissions Within Some Important Directories

[ref]   Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.

Group   Restrict Dynamic Mounting and Unmounting of Filesystems

[ref]   Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system.

This command can be used to list the types of filesystems that are available to the currently executing kernel:

$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d.

Group   Execution Settings

[ref]  

Group   Restrict Partition Mount Options

[ref]   System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the /etc/fstab configuration file, and can be used to make certain types of malicious behavior more difficult.

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.