Guide to the Secure Configuration of Fedora
with profile Standard System Security ProfileThis profile contains rules to ensure standard security baseline of a Fedora system. Regardless of your system's workload all of these checks should pass.
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).
Profile Title | Standard System Security Profile |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_standard |
Revision History
Current version: 0.1.30
- draft (as of 2016-06-27)
Platforms
- cpe:/o:fedoraproject:fedora:25
- cpe:/o:fedoraproject:fedora:24
- cpe:/o:fedoraproject:fedora:23
- cpe:/o:fedoraproject:fedora:22
Table of Contents
Checklist
contains 9 rules |
System Settingsgroup |
contains 9 rules |
Installing and Maintaining SoftwaregroupThe 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 SoftwaregroupThe |
contains 1 rule |
gpgcheck Enabled In Main Dnf ConfigurationruleThe gpgcheck=1Rationale: Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering. |
Software Integrity Checkinggroup
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.
|
contains 2 rules |
Verify Integrity with RPMgroupThe 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 -qVaSee the man page for rpm to see a complete explanation of each column.
|
contains 2 rules |
Verify and Correct File Permissions with RPMruleThe 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 FILENAMENext, run the following command to reset its permissions to the correct values: # rpm --setperms PACKAGENAMERationale: 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. |
Verify File Hashes with RPMruleThe 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 FILENAMEThe package can be reinstalled from a dnf repository using the command: dnf reinstall PACKAGENAMEAlternatively, the package can be reinstalled from trusted media using the command: rpm -Uvh PACKAGENAMERationale: 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. |
File Permissions and MasksgroupTraditional 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. |
contains 4 rules |
Verify Permissions on Important Files and DirectoriesgroupPermissions 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 DirectoriesgroupSome 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 PermissionsruleSystem-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/lib64Kernel 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 FILERationale: 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. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Verify that Shared Library Files Have Root OwnershipruleSystem-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/lib64Kernel 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 FILERationale: 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. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Verify that System Executables Have Restrictive PermissionsruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll 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 FILERationale: 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. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Verify that System Executables Have Root OwnershipruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll 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 FILERationale: 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. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Account and Access ControlgroupIn 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 LogingroupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the |
contains 1 rule |
Proper Storage and Existence of Password Hashesgroup
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
|
contains 1 rule |
Log In to Accounts With Empty Password ImpossibleruleIf 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 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. references: IA-5(b), IA-5(c), IA-5(1)(a) |
Secure Session Configuration Files for Login AccountsgroupWhen 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 PathgroupThe 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. |
contains 1 rule |
Ensure that Root's Path Does Not Include World or Group-Writable DirectoriesruleFor each element in root's path, run: $ sudo ls -ld DIRand 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. |