Guide to the Secure Configuration of WRLinux
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.
Profile Information
Profile ID | (default) |
---|
CPE Platforms
- cpe:/o:windriver:wrlinux:8
Revision History
Current version: 0.1.39
- draft (as of 2021-02-28)
Table of Contents
- Remediation functions used by the SCAP Security Guide Project
- Services
- Audit Settings
- Ftp Settings
- Ntp Settings
- Snmp Settings
- Cron and At Daemons
- Base Services
- Nfs Settings
- ssh Settings
- Xorg Settings
- System Settings
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.
| |
Group Audit Settings | |
Group Ftp Settings | |
Group Ntp Settings | |
Group Snmp Settings | |
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 | |
Group ssh Settings | |
Group Xorg Settings | |
Group System Settings | |
[ref] Contains rules that check correct system settings. | |
Group Logging Settings | |
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 | |
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 | |
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 | |
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 | |
Group Set Password Expiration Parameters | |
[ref]
The file # chage -M 180 -m 7 -W 7 USER | |
Group Account expiration Settings | |
Group Banners Settings | |
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 $PATHThis 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 | |
Group pam Settings | |
Group Physical Settings | |
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.
$ 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 | |
[ref]
The default restrictive permissions for files which act as important security databases such as | |
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.
$ 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 | |
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 | |
Group Auditing Settings | |
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 | |
Group Gnome Settings | |
Group Updating Settings | |