Guide to the Secure Configuration of Fedora

with profile Standard System Security Profile
This profile contains rules to ensure standard security baseline of a Fedora system. Regardless of your system's workload all of these checks should pass.

This guide presents a catalog of security-relevant configuration settings for Fedora. 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 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 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 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 Fedora, 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 TitleStandard System Security Profile
Profile IDxccdf_org.ssgproject.content_profile_standard

Revision History

Current version: 0.1.34

  • draft (as of 2017-06-29)

Platforms

  • cpe:/o:fedoraproject:fedora:25
  • cpe:/o:fedoraproject:fedora:24
  • cpe:/o:fedoraproject:fedora:23

Table of Contents

  1. System Settings
    1. Installing and Maintaining Software
    2. File Permissions and Masks
    3. Account and Access Control

Checklist

contains 9 rules

System Settings   [ref]group

Contains rules that check correct system settings.

contains 9 rules

Installing and Maintaining Software   [ref]group

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

contains 3 rules

Updating Software   [ref]group

The dnf command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.

Fedora systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Tools such as dnf or the graphical Software Update ensure usage of RPM packages for software installation. This allows for insight into the current inventory of installed software on the system, and is highly recommended.

contains 1 rule

gpgcheck Enabled In Main Dnf Configuration   [ref]rule

The gpgcheck option should be used to ensure checking of an RPM package's signature always occurs prior to its installation. To configure dnf to check package signatures before installing them, ensure the following line appears in /etc/dnf/dnf.conf in the [main] section:

gpgcheck=1

Rationale:

Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering.

Severity:  high

References:  SI-7, MA-1(b), 352, 663

Remediation Ansible snippet:   (show)

Complexity:low
Disruption:medium
- name: "Check existence of yum on Fedora"
  stat:
    path: /etc/yum.conf
  register: yum_config_file
  check_mode: no
  when: ansible_distribution == "Fedora"

# Old versions of Fedora use yum

- name: "Ensure GPG check is globally activated (yum)"
  ini_file:
    dest: "{{item}}"
    section: main
    option: gpgcheck
    value: 1
    create: False
  with_items: "/etc/yum.conf"
  when: ansible_distribution == "RedHat" or yum_config_file.stat.exists
  tags:
    - ensure_gpgcheck_globally_activated
    - high

- name: "Ensure GPG check is globally activated (dnf)"
  ini_file:
    dest: "{{item}}"
    section: main
    option: gpgcheck
    value: 1
    create: False
  with_items: "/etc/dnf/dnf.conf"
  when: ansible_distribution == "Fedora"
  tags:
    - ensure_gpgcheck_globally_activated
    - high

Software Integrity Checking   [ref]group

Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.

Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

contains 2 rules

Verify Integrity with RPM   [ref]group

The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database:

# rpm -qVa
See the man page for rpm to see a complete explanation of each column.

contains 2 rules

Verify and Correct File Permissions with RPM   [ref]rule

The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it:

# rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
# rpm --setperms PACKAGENAME

Rationale:

Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Severity:  low

References:  AC-6, CM-6(d), CM-6(3), 1493, 1494, 1495

Remediation Ansible snippet:   (show)

Complexity:high
Disruption:medium
Strategy:restrict
- name: "Read list of files with incorrect permissions"
  shell: "rpm -Va | grep '^.M' | sed -r 's;^.*\\s+(.+);\\1;g'"
  register: files_with_incorrect_permissions
  failed_when: False
  changed_when: False
  check_mode: no
  tags:
    - rpm_verify_permissions
    - low

- name: "Correct file permissions with RPM"
  shell: "rpm --setperms $(rpm -qf '{{item}}')"
  with_items: "{{ files_with_incorrect_permissions.stdout_lines }}"
  when: files_with_incorrect_permissions.stdout_lines | length > 0
  tags:
    - rpm_verify_permissions
    - low

Verify File Hashes with RPM   [ref]rule

The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database:

# rpm -Va | grep '^..5'
A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file:
# rpm -qf FILENAME
The package can be reinstalled from a dnf repository using the command:
dnf reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
rpm -Uvh PACKAGENAME

Rationale:

The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.

Severity:  low

References:  CM-6(d), CM-6(3), SI-7, 1496

Remediation Ansible snippet:   (show)

Complexity:high
Disruption:medium
- name: "Set fact: Package manager reinstall command (dnf)"
  set_fact:
    package_manager_reinstall_cmd: dnf reinstall -y
  when: ansible_distribution == "Fedora"
  tags:
    - rpm_verify_hashes
    - low

- name: "Set fact: Package manager reinstall command (yum)"
  set_fact:
    package_manager_reinstall_cmd: yum reinstall -y
  when: ansible_distribution == "RedHat"
  tags:
    - rpm_verify_hashes
    - low

- name: "Read files with incorrect hash"
  shell: "rpm -Va | grep -E '^..5.* /(bin|sbin|lib|lib64|usr)/' | sed -r 's;^.*\\s+(.+);\\1;g'"
  register: files_with_incorrect_hash
  changed_when: False
  when: package_manager_reinstall_cmd is defined
  check_mode: no
  tags:
    - rpm_verify_hashes
    - low

- name: "Reinstall packages of files with incorrect hash"
  shell: "{{package_manager_reinstall_cmd}} $(rpm -qf '{{item}}')"
  with_items: "{{ files_with_incorrect_hash.stdout_lines }}"
  when: package_manager_reinstall_cmd is defined and (files_with_incorrect_hash.stdout_lines | length > 0)
  tags:
    - rpm_verify_hashes
    - low

File Permissions and Masks   [ref]group

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.

contains 4 rules

Verify Permissions on Important Files and Directories   [ref]group

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.

contains 4 rules

Verify File Permissions Within Some Important Directories   [ref]group

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.

contains 4 rules

Verify that Shared Library Files Have Restrictive Permissions   [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.

Severity:  medium

Remediation Ansible snippet:   (show)

Complexity:high
Disruption:medium
Strategy:restrict
- name: "Read list of world and group writable files in libraries directories"
  shell: "find /lib /lib64 /usr/lib /usr/lib64 -perm /022 -type f"
  register: world_writable_library_files
  changed_when: False
  failed_when: False
  check_mode: no
  tags:
    - file_permissions_library_dirs
    - medium

- name: "Disable world/group writability to library files"
  file:
    path: "{{item}}"
    mode: "go-w"
  with_items: "{{ world_writable_library_files.stdout_lines }}"
  when: world_writable_library_files.stdout_lines | length > 0
  tags:
    - file_permissions_library_dirs
    - medium

Verify that Shared Library Files Have Root Ownership   [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command:
$ sudo chown root FILE

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system.

Severity:  medium

Remediation Shell script:   (show)

for LIBDIR in /usr/lib /usr/lib64 /lib /lib64
do
  if [ -d $LIBDIR ]
  then
    find -L $LIBDIR \! -user root -exec chown root {} \; 
  fi
done
Remediation Ansible snippet:   (show)

Complexity:medium
Disruption:medium
Strategy:restrict
- name: "Read list libraries without root ownership"
  shell: "find -L /usr/lib /usr/lib64 /lib /lib64 \\! -user root"
  register: libraries_not_owned_by_root
  changed_when: False
  failed_when: False
  check_mode: no
  tags:
    - file_ownership_library_dirs
    - medium

- name: "Set ownership of system libraries to root"
  file:
    path: "{{item}}"
    owner: "root"
  with_items: "{{ libraries_not_owned_by_root.stdout_lines }}"
  when: libraries_not_owned_by_root | length > 0
  tags:
    - file_ownership_library_dirs
    - medium

Verify that System Executables Have Restrictive Permissions   [ref]rule

System executables are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE

Rationale:

System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.

Severity:  medium

Remediation Ansible snippet:   (show)

Complexity:medium
Disruption:medium
Strategy:restrict
- name: "Read list of world and group writable system executables"
  shell: "find /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin /usr/libexec -perm /022 -type f"
  register: world_writable_library_files
  changed_when: False
  failed_when: False
  check_mode: no
  tags:
    - file_permissions_binary_dirs
    - medium

- name: "Remove world/group writability of system executables"
  file:
    path: "{{item}}"
    mode: "go-w"
  with_items: "{{ world_writable_library_files.stdout_lines }}"
  when: world_writable_library_files.stdout_lines | length > 0
  tags:
    - file_permissions_binary_dirs
    - medium

Verify that System Executables Have Root Ownership   [ref]rule

System executables are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:
$ sudo chown root FILE

Rationale:

System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.

Severity:  medium

Remediation Ansible snippet:   (show)

Complexity:medium
Disruption:medium
Strategy:restrict
- name: "Read list of system executables without root ownership"
  shell: "find /bin/ /usr/bin/ /usr/local/bin/ /sbin/ /usr/sbin/ /usr/local/sbin/ /usr/libexec \\! -user root"
  register: no_root_system_executables
  changed_when: False
  failed_when: False
  check_mode: no
  tags:
    - file_ownership_binary_dirs
    - medium

- name: "Set ownership to root of system executables"
  file:
    path: "{{item}}"
    owner: "root"
  with_items: "{{ no_root_system_executables.stdout_lines }}"
  when: no_root_system_executables.stdout_lines | length > 0
  tags:
    - file_ownership_binary_dirs
    - medium

Account and Access Control   [ref]group

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 Fedora.

contains 2 rules

Protect Accounts by Restricting Password-Based Login   [ref]group

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.

contains 1 rule

Proper Storage and Existence of Password Hashes   [ref]group

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.

contains 1 rule

Log In to Accounts With Empty Password Impossible   [ref]rule

If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords.

Rationale:

If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

Severity:  high

References:  IA-5(b), IA-5(c), IA-5(1)(a)

Remediation Shell script:   (show)

sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/system-auth
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:medium
Strategy:configure
- name: "Prevent Log In to Accounts With Empty Password"
  replace:
    dest: /etc/pam.d/system-auth
    regexp: 'nullok\s*'
    replace: ''
  tags:
    - no_empty_passwords
    - high

Secure Session Configuration Files for Login Accounts   [ref]group

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.

contains 1 rule

Ensure that No Dangerous Directories Exist in Root's Path   [ref]group

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.

contains 1 rule

Ensure that Root's Path Does Not Include World or Group-Writable Directories   [ref]rule

For each element in root's path, run:

$ sudo ls -ld DIR
and ensure that write permissions are disabled for group and other.

Rationale:

Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code.

Severity:  low

References:  CM-6(b), 366

Remediation Ansible snippet:   (show)

Complexity:low
Disruption:medium
Strategy:restrict
- name: "Fail if user is not root"
  fail:
    msg: 'Root account required to read root $PATH'
  when: ansible_user != "root"
  tags:
    - accounts_root_path_dirs_no_write
    - low

- name: "Get root paths which are not symbolic links"
  shell: 'tr ":" "\n" <<< "$PATH" | xargs -I% find % -maxdepth 0 -type d'
  changed_when: False
  failed_when: False
  register: root_paths
  when: ansible_user == "root"
  check_mode: no
  tags:
    - accounts_root_path_dirs_no_write
    - low

- name: "Disable writability to root directories"
  file:
    path: "{{item}}"
    mode: "g-w,o-w"
  with_items: "{{ root_paths.stdout_lines }}"
  when: root_paths.stdout_lines is defined
  tags:
    - accounts_root_path_dirs_no_write
    - low

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.