Group
Guide to the Secure Configuration of Debian 12
Group contains 76 groups and 390 rules |
Group
System Settings
Group contains 51 groups and 307 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 6 groups and 36 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
Group
System and Software Integrity
Group contains 2 groups and 7 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for 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. |
Group
Software Integrity Checking
Group contains 1 group and 7 rules |
[ref]
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. |
Group
Verify Integrity with AIDE
Group contains 7 rules |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION
. |
Rule
Install AIDE
[ref] | The aide package can be installed with the following command:
$ apt-get install aide
| Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-002699, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | ism | 1034, 1288, 1341, 1417 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | anssi | R76, R79 | pcidss4 | 11.5.2 |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo aideinit
By default, the database will be written to the file
/var/lib/aide/aide.db.new .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/sbin/aide
(or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate. | Rationale: | For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_build_database | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | anssi | R76, R79 | pcidss4 | 11.5.2 |
| |
|
Rule
Configure Systemd Timer Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a systemd service and a timer unit to run the service periodically:
For example, if a systemd timer is expected to be started every day at 5AM
OnCalendar=*-*-* 05:00:0
[Timer] section in the timer unit and
a Unit section starting the AIDE check service unit should be referred. | Rationale: | AIDE provides a means to check if unauthorized changes are made to the system.
AIDE itself does not setup a periodic execution, so in order to detect unauthorized
changes a systemd service to run the check and a systemd timer to take care
of periodical execution of that systemd service should be defined. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_checking_systemd_timer | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-001744, CCI-002699, CCI-002702 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | anssi | R76 | pcidss4 | 11.5.2 |
| |
|
Rule
Configure Periodic Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * * root /usr/sbin/aide --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * 0 root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example.
The usage of cron's special time codes, such as @daily and
@weekly is acceptable. | Rationale: | By default, AIDE does not install itself for periodic execution. Periodically
running AIDE is necessary to reveal unexpected changes in installed files.
Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_cron_checking | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-001744, CCI-002699, CCI-002702 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | anssi | R76 | pcidss4 | 11.5.2 |
| |
|
Rule
Configure Notification of Post-AIDE Scan Details
[ref] | AIDE should notify appropriate personnel of the details of a scan after the scan has been run.
If AIDE has already been configured for periodic execution in /etc/crontab , append the
following line to the existing AIDE line:
| /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
Otherwise, add the following line to /etc/crontab :
05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
AIDE can be executed periodically through other means; this is merely one example. | Rationale: | Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_scan_notification | References: | cis-csc | 1, 11, 12, 13, 15, 16, 2, 3, 5, 7, 8, 9 | cobit5 | BAI01.06, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07 | disa | CCI-001744, CCI-002699, CCI-002702 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 6.2, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.4.1, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1 | nist | CM-6(a), CM-3(5) | nist-csf | DE.CM-1, DE.CM-7, PR.IP-1, PR.IP-3 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | anssi | R76 |
| |
|
Rule
Configure AIDE to Verify Access Control Lists (ACLs)
[ref] | By default, the acl option is added to the FIPSR ruleset in AIDE.
If using a custom ruleset or the acl option is missing, add acl
to the appropriate ruleset.
For example, add acl to the following line in /etc/aide.conf :
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default.
The remediation provided with this rule adds acl to all rule sets available in
/etc/aide.conf
| Rationale: | ACLs can provide permissions beyond those permitted through the file mode and must be
verified by the file integrity tools. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_aide_verify_acls | References: | cis-csc | 2, 3 | cobit5 | APO01.06, BAI03.05, BAI06.01, DSS06.02 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8 | iso27001-2013 | A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | PR.DS-6, PR.DS-8 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R76 |
| |
|
Rule
Configure AIDE to Verify Extended Attributes
[ref] | By default, the xattrs option is added to the FIPSR ruleset in AIDE.
If using a custom ruleset or the xattrs option is missing, add xattrs
to the appropriate ruleset.
For example, add xattrs to the following line in /etc/aide.conf :
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default.
The remediation provided with this rule adds xattrs to all rule sets available in
/etc/aide.conf
| Rationale: | Extended attributes in file systems are used to contain arbitrary data and file metadata
with security implications. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_aide_verify_ext_attributes | References: | cis-csc | 2, 3 | cobit5 | APO01.06, BAI03.05, BAI06.01, DSS06.02 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8 | iso27001-2013 | A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | PR.DS-6, PR.DS-8 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R76 |
| |
|
Group
Disk Partitioning
Group contains 9 rules |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/ , /boot , and swap .
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/ 's logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible. |
Rule
Ensure /boot Located On Separate Partition
[ref] | It is recommended that the /boot directory resides on a separate
partition. This makes it easier to apply restrictions e.g. through the
noexec mount option. Eventually, the /boot partition can
be configured not to be mounted automatically with the noauto mount
option. | Rationale: | The /boot partition contains the kernel and bootloader files.
Access to this partition should be restricted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_boot | References: | | |
|
Rule
Ensure /home Located On Separate Partition
[ref] | If user home directories will be stored locally, create a separate partition
for /home at installation time (or migrate it later using LVM). If
/home will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later. | Rationale: | Ensuring that /home is mounted on its own partition enables the
setting of more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_home | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS05.02 | disa | CCI-000366, CCI-001208 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | nist | CM-6(a), SC-5(2) | nist-csf | PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R28 |
| |
|
Rule
Ensure /opt Located On Separate Partition
[ref] | It is recommended that the /opt directory resides on a separate
partition. | Rationale: | The /opt partition contains additional software, usually installed
outside the packaging system. Putting this directory on a separate partition
makes it easier to apply restrictions e.g. through the nosuid mount
option. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_opt | References: | | |
|
Rule
Ensure /srv Located On Separate Partition
[ref] | If a file server (FTP, TFTP...) is hosted locally, create a separate partition
for /srv at installation time (or migrate it later using LVM). If
/srv will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later. | Rationale: | Srv deserves files for local network file server such as FTP. Ensuring
that /srv is mounted on its own partition enables the setting of
more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_srv | References: | | |
|
Rule
Ensure /usr Located On Separate Partition
[ref] | It is recommended that the /usr directory resides on a separate
partition. | Rationale: | The /usr partition contains system software, utilities and files.
Putting it on a separate partition allows limiting its size and applying
restrictions through mount options. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_usr | References: | | |
|
Rule
Ensure /var Located On Separate Partition
[ref] | The /var directory is used by daemons and other system
services to store frequently-changing data. Ensure that /var has its own partition
or logical volume at installation time, or migrate it using LVM. | Rationale: | Ensuring that /var is mounted on its own partition enables the
setting of more restrictive mount options. This helps protect
system services such as daemons or other programs which use it.
It is not uncommon for the /var directory to contain
world-writable directories installed by other software packages. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS05.02 | disa | CCI-000366 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | nist | CM-6(a), SC-5(2) | nist-csf | PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R28 |
| |
|
Rule
Ensure /var/log Located On Separate Partition
[ref] | System logs are stored in the /var/log directory.
Ensure that /var/log has its own partition or logical
volume at installation time, or migrate it using LVM. | Rationale: | Placing /var/log in its own partition
enables better separation between log files
and other files in /var/ . | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log | References: | cis-csc | 1, 12, 14, 15, 16, 3, 5, 6, 8 | cobit5 | APO11.04, APO13.01, BAI03.05, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3 | nerc-cip | CIP-007-3 R6.5 | nist | CM-6(a), AU-4, SC-5(2) | nist-csf | PR.PT-1, PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R28 |
| |
|
Rule
Ensure /var/log/audit Located On Separate Partition
[ref] | Audit logs are stored in the /var/log/audit directory.
Ensure that /var/log/audit has its own partition or logical
volume at installation time, or migrate it using LVM.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon. | Rationale: | Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log_audit | References: | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8 | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366, CCI-001849 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1 | nerc-cip | CIP-007-3 R6.5 | nist | CM-6(a), AU-4, SC-5(2) | nist-csf | PR.DS-4, PR.PT-1, PR.PT-4 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227 | app-srg-ctr | SRG-APP-000357-CTR-000800 | anssi | R71 |
| |
|
Rule
Ensure /var/tmp Located On Separate Partition
[ref] | The /var/tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM. | Rationale: | The /var/tmp partition is used as temporary storage by many programs.
Placing /var/tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_tmp | References: | | |
|
Group
Sudo
Group contains 18 rules |
[ref]
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ apt-get install sudo
| Rationale: | sudo is a program designed to allow a system administrator to give
limited root privileges to users and log root activity. The basic philosophy
is to give as few privileges as possible but still allow system users to
get their work done.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_sudo_installed | References: | | |
|
Rule
Verify Group Who Owns /etc/sudoers.d Directory
[ref] | To properly set the group owner of /etc/sudoers.d , run the command: $ sudo chgrp root /etc/sudoers.d
| Rationale: | The ownership of the /etc/sudoers.d directory by the root group is important
because this directory hosts sudo configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_sudoersd | References: | | |
|
Rule
Verify User Who Owns /etc/sudoers.d Directory
[ref] | To properly set the owner of /etc/sudoers.d , run the command: $ sudo chown root /etc/sudoers.d
| Rationale: | The ownership of the /etc/sudoers.d directory by the root user is important
because this directory hosts sudo configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_sudoersd | References: | | |
|
Rule
Verify Permissions On /etc/sudoers.d Directory
[ref] | To properly set the permissions of /etc/sudoers.d , run the command: $ sudo chmod 0750 /etc/sudoers.d
| Rationale: | Setting correct permissions on the /etc/sudoers.d directory is important
because this directory hosts sudo configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the sudo configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_sudoersd | References: | | |
|
Rule
Verify Group Who Owns /etc/sudoers File
[ref] | To properly set the group owner of /etc/sudoers , run the command: $ sudo chgrp root /etc/sudoers
| Rationale: | The ownership of the /etc/sudoers file by the root group is important
because this file hosts sudo configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_sudoers | References: | | |
|
Rule
Verify User Who Owns /etc/sudoers File
[ref] | To properly set the owner of /etc/sudoers , run the command: $ sudo chown root /etc/sudoers
| Rationale: | The ownership of the /etc/sudoers file by the root user is important
because this file hosts sudo configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_sudoers | References: | | |
|
Rule
Verify Permissions On /etc/sudoers File
[ref] | To properly set the permissions of /etc/sudoers , run the command: $ sudo chmod 0440 /etc/sudoers
| Rationale: | Setting correct permissions on the /etc/sudoers file is important
because this file hosts sudo configuration. Protection of this
file is critical for system security. Restricting the permissions
ensures exclusive control of the sudo configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_sudoers | References: | | |
|
Rule
Ensure That the sudo Binary Has the Correct Permissions
[ref] |
To properly set the permissions of /usr/bin/sudo , run the command:
$ sudo chmod 4111 /usr/bin/sudo
| Rationale: | The sudoers program should only be usable by people who have the correct permissions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_sudo | References: | | |
|
Rule
Ensure sudo Runs In A Minimal Environment - sudo env_reset
[ref] | The sudo env_reset tag, when specified, will run the command in a minimal environment,
containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER and SUDO_* variables.
This should be enabled by making sure that the env_reset tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Forcing sudo to reset the environment ensures that environment variables are not passed on to the
command accidentaly, preventing leak of potentially sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_env_reset | References: | | |
|
Rule
Ensure sudo Ignores Commands In Current Dir - sudo ignore_dot
[ref] | The sudo ignore_dot tag, when specified, will ignore the current directory
in the PATH environment variable.
This should be enabled by making sure that the ignore_dot tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Ignoring the commands in the user's current directory prevents an attacker from executing commands
downloaded locally. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_ignore_dot | References: | | |
|
Rule
Ensure Privileged Escalated Commands Cannot Execute Other Commands - sudo NOEXEC
[ref] | The sudo NOEXEC tag, when specified, prevents user executed
commands from executing other commands, like a shell for example.
This should be enabled by making sure that the NOEXEC tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Restricting the capability of sudo allowed commands to execute sub-commands
prevents users from running programs with privileges they wouldn't have otherwise. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_noexec | References: | | |
|
Rule
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo requiretty
[ref] | The sudo requiretty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the requiretty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Restricting the use cases in which a user is allowed to execute sudo commands
reduces the attack surface. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_requiretty | References: | | |
|
Rule
Ensure sudo umask is appropriate - sudo umask
[ref] | The sudo umask tag, when specified, will be added the to the user's umask in the
command environment.
The umask should be configured by making sure that the umask=0077
tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_umask | References: | | |
|
Rule
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty
[ref] | The sudo use_pty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the use_pty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining
access to the user's terminal after the main program has finished executing. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_use_pty | References: | | |
|
Rule
Ensure a dedicated group owns sudo
[ref] | Restrict the execution of privilege escalated commands to a dedicated group of users.
Ensure the group owner of /usr/bin/sudo is sudogrp. Warning:
Changing group owner of /usr/bin/sudo to a group with no member users will prevent
any and all escalatation of privileges.
Additionally, the system may become unmanageable if root logins are not allowed. Warning:
This rule doesn't come with a remediation, before remediating the sysadmin needs to add users to the dedicated sudo group. | Rationale: | Restricting the set of users able to execute commands as privileged user reduces the attack surface. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_dedicated_group | References: | | |
|
Rule
Explicit arguments in sudo specifications
[ref] | All commands in the sudoers file must strictly specify the arguments allowed to be used for a given user.
If the command is supposed to be executed only without arguments, pass "" as an argument in the corresponding user specification. Warning:
This rule doesn't come with a remediation, as absence of arguments in the user spec doesn't mean that the command is intended to be executed with no arguments. Warning:
The rule can produce false findings when an argument contains a comma - sudoers syntax allows comma escaping using backslash, but the check doesn't support that. For example, root ALL=(ALL) echo 1\,2 allows root to execute echo 1,2 , but the check would interpret it as two commands echo 1\ and 2 . | Rationale: | Any argument can modify quite significantly the behavior of a program, whether regarding the
realized operation (read, write, delete, etc.) or accessed resources (path in a file system tree). To
avoid any possibility of misuse of a command by a user, the ambiguities must be removed at the
level of its specification.
For example, on some systems, the kernel messages are only accessible by root.
If a user nevertheless must have the privileges to read them, the argument of the dmesg command has to be restricted
in order to prevent the user from flushing the buffer through the -c option:
user ALL = dmesg ""
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_explicit_command_args | References: | | |
|
Rule
Don't define allowed commands in sudoers by means of exclusion
[ref] | Policies applied by sudo through the sudoers file should not involve negation.
Each user specification in the sudoers file contains a comma-delimited list of command specifications.
The definition can make use glob patterns, as well as of negations.
Indirect definition of those commands by means of exclusion of a set of commands is trivial to bypass, so it is not allowed to use such constructs. Warning:
This rule doesn't come with a remediation, as negations indicate design issues with the sudoers user specifications design. Just removing negations doesn't increase the security - you typically have to rethink the definition of allowed commands to fix the issue. | Rationale: | Specifying access right using negation is inefficient and can be easily circumvented.
For example, it is expected that a specification like
# To avoid absolutely , this rule can be easily circumvented!
user ALL = ALL ,!/ bin/sh
prevents the execution of the shell
but that’s not the case: just copy the binary /bin/sh to a different name to make it executable
again through the rule keyword ALL . | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_no_command_negation | References: | | |
|
Rule
Don't target root user in the sudoers file
[ref] | The targeted users of a user specification should be, as much as possible, non privileged users (i.e.: non-root).
User specifications have to explicitly list the runas spec (i.e. the list of target users that can be impersonated), and ALL or root should not be used. Warning:
This rule doesn't come with a remediation, as the exact requirement allows exceptions, and removing lines from the sudoers file can make the system non-administrable. | Rationale: | It is common that the command to be executed does not require superuser rights (editing a file
whose the owner is not root, sending a signal to an unprivileged process,etc.). In order to limit
any attempt of privilege escalation through a command, it is better to apply normal user rights. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_no_root_target | References: | | |
|
Group
Updating Software
Group contains 1 rule |
[ref]
The apt_get 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.
Debian 12 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
apt_get or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure Software Patches Installed
[ref] |
If the system has an apt repository available, run the following command to install updates:
$ apt update && apt full-upgrade
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. Warning:
The OVAL feed of Debian 12 is not a XML file, which may not be understood by all scanners. | Rationale: | Installing software updates is a fundamental mitigation against
the exploitation of publicly-known vulnerabilities. If the most
recent security patches and updates are not installed, unauthorized
users may take advantage of weaknesses in the unpatched software. The
lack of prompt attention to patching could result in a system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_security_patches_up_to_date | References: | cis-csc | 18, 20, 4 | cjis | 5.10.4.1 | cobit5 | APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02 | disa | CCI-000366, CCI-001227 | isa-62443-2009 | 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9 | iso27001-2013 | A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 | nist | SI-2(5), SI-2(c), CM-6(a) | nist-csf | ID.RA-1, PR.IP-12 | ospp | FMT_MOF_EXT.1 | pcidss | Req-6.2 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R61 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Prefer to use a 64-bit Operating System when supported
[ref] | Prefer installation of 64-bit operating systems when the CPU supports it. Warning:
There is no remediation besides installing a 64-bit operating system. | Rationale: | Use of a 64-bit operating system offers a few advantages, like a larger address space range for
Address Space Layout Randomization (ASLR) and systematic presence of No eXecute and Execute Disable (NX/XD) protection bits. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_prefer_64bit_os | References: | | |
|
Group
Account and Access Control
Group contains 12 groups and 27 rules |
[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
Debian 12. |
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 13 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
Group
Set Lockouts for Failed Password Attempts
Group contains 4 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock .
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Limit Password Reuse
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_unix or pam_pwhistory PAM modules. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report. Warning:
Newer versions of authselect contain an authselect feature to easily and properly
enable pam_pwhistory.so module. If this feature is not yet available in your
system, an authselect custom profile must be used to avoid integrity issues in PAM files. | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not
re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_remember | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | disa | CCI-000200 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(e) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.5 | os-srg | SRG-OS-000077-GPOS-00045 | anssi | R31 | pcidss4 | 8.3.7, 8.3 |
| |
|
Rule
Lock Accounts After Failed Password Attempts
[ref] | This rule configures the system to lock out accounts after a number of incorrect login attempts
using pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected.
Ensure that the file /etc/security/faillock.conf contains the following entry:
deny = <count>
Where count should be less than or equal to
3 and greater than 0. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via
user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking
the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.3 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.8 | disa | CCI-000044, CCI-002236, CCI-002237, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | pcidss | Req-8.1.6 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
Rule
Set Interval For Counting Failed Password Attempts
[ref] | Utilizing pam_faillock.so , the fail_interval directive configures the system
to lock out an account after a number of incorrect login attempts within a specified time
period.
Ensure that the file /etc/security/faillock.conf contains the following entry:
fail_interval = <interval-in-seconds> where interval-in-seconds is 900 or greater. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-000044, CCI-002236, CCI-002237, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 |
| |
|
Rule
Set Lockout Time for Failed Password Attempts
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_faillock.so .
Ensure that the file /etc/security/faillock.conf contains the following entry:
unlock_time=<interval-in-seconds> where
interval-in-seconds is 900 or greater.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid any errors when manually editing these files,
it is recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version.
If unlock_time is set to 0 , manual intervention by an administrator is required
to unlock a user. This should be done using the faillock tool. Warning:
If the system supports the new /etc/security/faillock.conf file but the
pam_faillock.so parameters are defined directly in /etc/pam.d/system-auth and
/etc/pam.d/password-auth , the remediation will migrate the unlock_time parameter
to /etc/security/faillock.conf to ensure compatibility with authselect tool.
The parameters deny and fail_interval , if used, also have to be migrated
by their respective remediation. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.3 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.8 | disa | CCI-000044, CCI-002236, CCI-002237, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | pcidss | Req-8.1.7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
Set Password Quality Requirements
Group contains 1 group and 7 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The man pages pam_pwquality(8)
provide information on the capabilities and configuration of
each. |
Group
Set Password Quality Requirements with pam_pwquality
Group contains 7 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth :
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Digit Characters
[ref] | The pam_pwquality module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000194, CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000071-GPOS-00039 | anssi | R31 | pcidss4 | 8.3.6, 8.3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters
[ref] | The pam_pwquality module's lcredit parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000193, CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000070-GPOS-00038 | anssi | R31 | pcidss4 | 8.3.6, 8.3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Categories
[ref] | The pam_pwquality module's minclass parameter controls
requirements for usage of different character classes, or types, of character
that must exist in a password before it is considered valid. For example,
setting this value to three (3) requires that any password must have characters
from at least three different categories in order to be approved. The default
value is zero (0), meaning there are no required classes. There are four
categories available:
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry
to require 4
differing categories of characters when changing passwords. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The
more complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised.
Requiring a minimum number of character categories makes password guessing attacks more difficult
by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000195 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | os-srg | SRG-OS-000072-GPOS-00040 | anssi | R68 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Length
[ref] | The pam_pwquality module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=15
after pam_pwquality to set minimum password length requirements. | Rationale: | The shorter the password, the lower the number of possible combinations
that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a
password in resisting attempts at guessing and brute-force attacks.
Password length is one factor of several that helps to determine strength
and how long it takes to crack a password. Use of more characters in a password
helps to exponentially increase the time and/or resources required to
compromise the password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000205, CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000078-GPOS-00046 | anssi | R31, R68 | pcidss4 | 8.3.6, 8.3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Special Characters
[ref] | The pam_pwquality module's ocredit= parameter controls requirements for
usage of special (or "other") characters in a password. When set to a negative number,
any password will be required to contain that many special characters.
When set to a positive number, pam_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting
in /etc/security/pwquality.conf to equal -1
to require use of a special character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-001619, CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000266-GPOS-00101 | anssi | R31 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
[ref] | To configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in
/etc/pam.d/common-password to show
retry=3
, or a lower value if site
policy is more restrictive. The DoD requirement is a maximum of 3 prompts
per session. | Rationale: | Setting the password retry prompts that are permitted on a per-session basis to a low value
requires some software, such as SSH, to re-connect. This can slow down and
draw additional attention to some types of password-guessing attacks. Note that this
is different from account lockout, which is provided by the pam_faillock module. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | References: | cis-csc | 1, 11, 12, 15, 16, 3, 5, 9 | cjis | 5.5.3 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000192, CCI-000366 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1 | ospp | FMT_MOF_EXT.1 | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227 | anssi | R68 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters
[ref] | The pam_pwquality module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more
complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000192, CCI-000193, CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038 | anssi | R31 |
| |
|
Group
Set Password Hashing Algorithm
Group contains 1 rule |
[ref]
The system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
Rule
Set Password Hashing Algorithm in /etc/login.defs
[ref] | In /etc/login.defs , add or update the following line to ensure the system will use
YESCRYPT as the hashing algorithm:
ENCRYPT_METHOD YESCRYPT
| Rationale: | Passwords need to be protected at all times, and encryption is the standard method for
protecting passwords. If passwords are not encrypted, they can be plainly read
(i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-000196 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
Install pam_pwquality Package
[ref] |
The libpam-pwquality package can be installed with the following command:
$ apt-get install libpam-pwquality
| Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure
of the effectiveness of a password in resisting attempts at guessing and
brute-force attacks. "pwquality" enforces complex password construction
configuration and has the ability to limit brute-force attacks on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_pam_pwquality_installed | References: | | |
|
Group
Protect Physical Console Access
Group contains 1 rule |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Rule
Configure Logind to terminate idle sessions after certain time of inactivity
[ref] | To configure logind service to terminate inactive user sessions
after 600 seconds, edit the file
/etc/systemd/logind.conf . Ensure that there is a section
[Login] which contains the configuration
StopIdleSessionSec=600
. | Rationale: | Terminating an idle session within a short time period reduces the window of
opportunity for unauthorized personnel to take control of a management
session enabled on the console or console port that has been let unattended. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_logind_session_timeout | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cjis | 5.5.6 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.1.11 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.14.1.1, A.14.2.1, A.14.2.5, A.18.1.4, A.6.1.2, A.6.1.5, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | CM-6(a), AC-17(a), AC-2(5), AC-12, AC-17(a), SC-10, CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.IP-2 | ospp | FMT_SMF_EXT.1.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000163-GPOS-00072 | anssi | R32 |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 3 groups and 3 rules |
[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
Group contains 1 rule |
[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:
$ sudo chage -M 180 -m 7 -W 7 USER
|
Rule
Set Root Account Password Maximum Age
[ref] | Configure the root account to enforce a 365-day maximum password lifetime restriction by running the following command:
$ sudo chage -M 365 root
| Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore,
passwords need to be changed periodically. If the operating system does
not limit the lifetime of passwords and force users to change their
passwords, there is the risk that the operating system passwords could be
compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_root | References: | | |
|
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 1 rule |
[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. |
Rule
Set number of Password Hashing Rounds - password-auth
[ref] | Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/common-password append rounds=11
to the pam_unix.so entry, as shown below:
password [success=1 default=ignore] pam_unix.so ...existing_options... rounds=11
Warning:
Setting a high number of hashing rounds makes it more difficult to brute force the password,
but requires more CPU resources to authenticate users. | Rationale: | Using a higher number of rounds makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_rounds_password_auth | References: | | |
|
Group
Restrict Root Logins
Group contains 1 rule |
[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. 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. |
Rule
Direct root Logins Not Allowed
[ref] | To further limit access to the root account, administrators
can disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to the system as root via Telnet, which sends the password in
plain text over the network. By default, Debian 12's
/etc/securetty file only allows the root user to login at the console
physically attached to the system. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
$ sudo echo > /etc/securetty
Warning:
This rule only checks the /etc/securetty file existence and its content.
If you need to restrict user access using the /etc/securetty file, make sure
the pam_securetty.so PAM module is properly enabled in relevant PAM files. | Rationale: | Disabling direct root logins ensures proper accountability and multifactor
authentication to privileged accounts. Users will first login, then escalate
to privileged (root) access via su / sudo. This is required for FISMA Low
and FISMA Moderate systems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_direct_root_logins | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.6 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | anssi | R33 | pcidss4 | 8.6.1, 8.6 |
| |
|
Group
Secure Session Configuration Files for Login Accounts
Group contains 1 group and 10 rules |
[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 Users Have Sensible Umask Values
Group contains 3 rules |
[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.
|
Rule
Ensure the Default Bash Umask is Set Correctly
[ref] | To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask setting in /etc/bashrc to read
as follows:
umask 077
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc | References: | cis-csc | 18 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.3 | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | anssi | R36 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in login.defs
[ref] | To ensure the default umask controlled by /etc/login.defs is set properly,
add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK 077
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | References: | cis-csc | 11, 18, 3, 9 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.1.1, A.14.2.1, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-1, PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228 | anssi | R36 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in /etc/profile
[ref] | To ensure the default umask controlled by /etc/profile is set properly,
add or correct the umask setting in /etc/profile to read as follows:
umask 077
Note that /etc/profile also reads scrips within /etc/profile.d directory.
These scripts are also valid files to set umask value. Therefore, they should also be
considered during the check and properly remediated, if necessary. | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile | References: | cis-csc | 18 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.3 | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | anssi | R36 |
| |
|
Rule
Set Interactive Session Timeout
[ref] | Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity.
The value of TMOUT should be exported and read only.
The TMOUT
setting in a file loaded by /etc/profile , e.g.
/etc/profile.d/tmout.sh should read as follows:
typeset -xr TMOUT=600
or
declare -xr TMOUT=600
Using the typeset keyword is preferred for wider compatibility with ksh and other shells. | Rationale: | Terminating an idle session within a short time period reduces
the window of opportunity for unauthorized personnel to take control of a
management session enabled on the console or console port that has been
left unattended. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_tmout | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.11 | disa | CCI-000057, CCI-001133, CCI-002361 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | AC-12, SC-10, AC-2(5), CM-6(a) | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | os-srg | SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010 | anssi | R32 | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
User Initialization Files Must Be Group-Owned By The Primary Group
[ref] | Change the group owner of interactive users files to the group found
in /etc/passwd for the user. To change the group owner of a local
interactive user home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USER/.INIT_FILE
This rule ensures every initialization file related to an interactive user
is group-owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the group-ownership
of their respective initialization files. | Rationale: | Local initialization files for interactive users are used to configure the
user's shell environment upon logon. Malicious modification of these files could
compromise accounts upon logon. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_dot_group_ownership | References: | | |
|
Rule
User Initialization Files Must Be Owned By the Primary User
[ref] | Set the owner of the user initialization files for interactive users to
the primary owner with the following command:
$ sudo chown USER /home/USER/.*
This rule ensures every initialization file related to an interactive user
is owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the ownership of
their respective initialization files. | Rationale: | Local initialization files are used to configure the user's shell environment
upon logon. Malicious modification of these files could compromise accounts upon
logon. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_dot_user_ownership | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Be Group-Owned By The Primary Group
[ref] | Change the group of a local interactive users files and directories to a
group that the interactive user is a member of. To change the group owner of a
local interactive users files and directories, use the following command:
$ sudo chgrp USER_GROUP /home/USER/FILE_DIR
This rule ensures every file or directory under the home directory related
to an interactive user is group-owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the group-ownership
of folders or files in their respective home directories. | Rationale: | If a local interactive users files are group-owned by a group of which the
user is not a member, unintended users may be able to access them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_groupownership | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Have a Valid Owner
[ref] | Either remove all files and directories from the system that
do not have a valid user, or assign a valid user to all unowned
files and directories. To assign a valid owner to a local
interactive user's files and directories, use the following command:
$ sudo chown -R USER /home/USER
This rule ensures every file or directory under the home directory related
to an interactive user is owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the ownership of
folders or files in their respective home directories. | Rationale: | If local interactive users do not own the files in their directories,
unauthorized users may be able to access them. Additionally, if files are not
owned by the user, this could be an indication of system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_ownership | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Have Mode 0750 Or Less Permissive
[ref] | Set the mode on files and directories in the local interactive user home
directory with the following command:
$ sudo chmod 0750 /home/USER/FILE_DIR
Files that begin with a "." are excluded from this requirement. | Rationale: | If a local interactive user files have excessive permissions, unintended users
may be able to access or modify them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_permissions | References: | | |
|
Rule
Ensure All User Initialization Files Have Mode 0740 Or Less Permissive
[ref] | Set the mode of the user initialization files to 0740 with the
following command:
$ sudo chmod 0740 /home/USER/.INIT_FILE
| Rationale: | Local initialization files are used to configure the user's shell environment
upon logon. Malicious modification of these files could compromise accounts upon
logon. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permission_user_init_files | References: | | |
|
Group
AppArmor
Group contains 5 rules |
[ref]
Many security vulnerabilities result from bugs in trusted programs. A trusted
program runs with privileges that attackers want to possess. The program fails
to keep that trust if there is a bug in the program that allows the attacker to
acquire said privilege.
AppArmor® is an application security solution designed specifically to apply
privilege confinement to suspect programs. AppArmor allows the administrator to
specify the domain of activities the program can perform by developing a
security profile. A security profile is a listing of files that the program may
access and the operations the program may perform. AppArmor secures
applications by enforcing good application behavior without relying on attack
signatures, so it can prevent attacks even if previously unknown
vulnerabilities are being exploited. |
Rule
Ensure AppArmor is installed
[ref] | AppArmor provide Mandatory Access Controls. | Rationale: | Without a Mandatory Access Control system installed only the default
Discretionary Access Control system will be available. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_apparmor_installed | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002235 | os-srg | SRG-OS-000368-GPOS-00154, SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000370-GPOS-00155 | anssi | R45 |
| |
|
Rule
Install the pam_apparmor Package
[ref] | The pam_apparmor package can be installed with the following command:
$ apt-get install pam_apparmor
| Rationale: | Protection of system integrity using AppArmor depends on this package being
installed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_pam_apparmor_installed | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235 | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | anssi | R45 |
| |
|
Rule
Enforce all AppArmor Profiles
[ref] | AppArmor profiles define what resources applications are able to access.
To set all profiles to enforce mode run the following command:
$ sudo aa-enforce /etc/apparmor.d/*
To list unconfined processes run the following command:
$ sudo apparmor_status | grep processes
Any unconfined processes may need to have a profile created or activated
for them and then be restarted. | Rationale: | Security configuration requirements vary from site to site. Some sites may
mandate a policy that is stricter than the default policy, which is perfectly
acceptable. This recommendation is intended to ensure that any policies that
exist on the system are activated. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_all_apparmor_profiles_enforced | References: | | |
|
Rule
Ensure AppArmor is Active and Configured
[ref] | Verify that the Apparmor tool is configured to
control whitelisted applications and user home directory access
control.
The apparmor service can be enabled with the following command:
$ sudo systemctl enable apparmor.service
| Rationale: | Using a whitelist provides a configuration management method for allowing
the execution of only authorized software. Using only authorized software
decreases risk by limiting the number of potential vulnerabilities.
The organization must identify authorized software programs and permit
execution of authorized software by adding each authorized program to the
"pam_apparmor" exception policy. The process used to identify software
programs that are authorized to execute on organizational information
systems is commonly referred to as whitelisting.
Verification of whitelisted software occurs prior to execution or at system
startup.
Users' home directories/folders may contain information of a sensitive
nature. Nonprivileged users should coordinate any sharing of information
with a System Administrator (SA) through shared resources.
Apparmor can confine users to their home directory, not allowing them to
make any changes outside of their own home directories. Confining users to
their home directory will minimize the risk of sharing information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_apparmor_configured | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235 | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | anssi | R45 |
| |
|
Rule
Ensure AppArmor is enabled in the bootloader configuration
[ref] | Configure AppArmor to be enabled at boot time and verify that it has not been
overwritten by the bootloader boot parameters.
Note: This recommendation is designed around the grub bootloader, if LILO or
another bootloader is in use in your environment, enact equivalent settings. | Rationale: | AppArmor must be enabled at boot time in your bootloader configuration to
ensure that the controls it provides are not overridden. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_enable_apparmor | References: | | |
|
Group
GRUB2 bootloader configuration
Group contains 2 groups and 26 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default Debian 12 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Group
Non-UEFI GRUB2 bootloader configuration
Group contains 7 rules |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Verify /boot/grub/grub.cfg Group Ownership
[ref] | The file /boot/grub/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub/grub.cfg , run the command:
$ sudo chgrp root /boot/grub/grub.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub/user.cfg Group Ownership
[ref] | The file /boot/grub/user.cfg should be group-owned by the root
group to prevent reading or modification of the file.
To properly set the group owner of /boot/grub/user.cfg , run the command:
$ sudo chgrp root /boot/grub/user.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. Non-root users who read the boot parameters
may be able to identify weaknesses in security upon boot and be able to exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub/grub.cfg User Ownership
[ref] | The file /boot/grub/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub/grub.cfg , run the command:
$ sudo chown root /boot/grub/grub.cfg
| Rationale: | Only root should be able to modify important boot parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub/user.cfg User Ownership
[ref] | The file /boot/grub/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/grub/user.cfg , run the command:
$ sudo chown root /boot/grub/user.cfg
| Rationale: | Only root should be able to modify important boot parameters. Also, non-root users who read
the boot parameters may be able to identify weaknesses in security upon boot and be able to
exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub/grub.cfg Permissions
[ref] | File permissions for /boot/grub/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub/grub.cfg , run the command:
$ sudo chmod 600 /boot/grub/grub.cfg
| Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub/user.cfg Permissions
[ref] | File permissions for /boot/grub/user.cfg should be set to 600.
To properly set the permissions of /boot/grub/user.cfg , run the command:
$ sudo chmod 600 /boot/grub/user.cfg
| Rationale: | Proper permissions ensure that only the root user can read or modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Set Boot Loader Password in grub2
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-setpassword
When prompted, enter the password that was selected.
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_password | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | cui | 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000080-GPOS-00048 | anssi | R5 |
| |
|
Group
UEFI GRUB2 bootloader configuration
Group contains 7 rules |
[ref]
UEFI GRUB2 bootloader configuration Warning:
UEFI generally uses vfat file systems, which does not support Unix-style permissions
managed by chmod command. In this case, in order to change file permissions for files
within /boot/efi it is necessary to update the mount options in /etc/fstab file and
reboot the system. |
Rule
Verify the UEFI Boot Loader grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg , run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_efi_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 |
| |
|
Rule
Verify /boot/grub2/user.cfg Group Ownership
[ref] | The file /boot/grub2/user.cfg should be group-owned by the
root group to prevent reading or modification of the file.
To properly set the group owner of /boot/grub2/user.cfg , run the command:
$ sudo chgrp root /boot/grub2/user.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. Non-root users who read the boot parameters
may be able to identify weaknesses in security upon boot and be able to exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_efi_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 |
| |
|
Rule
Verify the UEFI Boot Loader grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg , run the command:
$ sudo chown root /boot/grub2/grub.cfg
| Rationale: | Only root should be able to modify important boot parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_efi_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 |
| |
|
Rule
Verify /boot/grub2/user.cfg User Ownership
[ref] | The file /boot/grub2/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/grub2/user.cfg , run the command:
$ sudo chown root /boot/grub2/user.cfg
| Rationale: | Only root should be able to modify important boot parameters. Also, non-root users who read
the boot parameters may be able to identify weaknesses in security upon boot and be able to
exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_efi_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 |
| |
|
Rule
Verify the UEFI Boot Loader grub.cfg Permissions
[ref] | File permissions for /boot/grub2/grub.cfg should be set to 700.
To properly set the permissions of /boot/grub2/grub.cfg , run the command:
$ sudo chmod 700 /boot/grub2/grub.cfg
| Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_efi_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 |
| |
|
Rule
Verify /boot/grub2/user.cfg Permissions
[ref] | File permissions for /boot/grub2/user.cfg should be set to 600.
To properly set the permissions of /boot/grub2/user.cfg , run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
| Rationale: | Proper permissions ensure that only the root user can read or modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_efi_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 |
| |
|
Rule
Set the UEFI Boot Loader Password
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-setpassword
When prompted, enter the password that was selected.
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_uefi_password | References: | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | cui | 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000080-GPOS-00048 | anssi | R5 |
| |
|
Rule
IOMMU configuration directive
[ref] | On x86 architecture supporting VT-d, the IOMMU manages the access control policy between the hardware devices and some
of the system critical units such as the memory.
Configure the default Grub2 kernel command line to contain iommu=force as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) iommu=force"
Warning:
Depending on the hardware, devices and operating system used, enabling IOMMU can cause hardware instabilities. Proper function and stability should be assessed before applying remediation to production systems. | Rationale: | On x86 architectures, activating the I/OMMU prevents the system from arbitrary accesses potentially made by
hardware devices. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_enable_iommu_force | References: | | |
|
Rule
Configure L1 Terminal Fault mitigations
[ref] | L1 Terminal Fault (L1TF) is a hardware vulnerability which allows unprivileged
speculative access to data which is available in the Level 1 Data Cache when
the page table entry isn't present.
Select the appropriate mitigation by adding the argument
l1tf=full,force
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain l1tf= full,force as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) l1tf=full,force"
Since Linux Kernel 4.19 you can check the L1TF vulnerability state with the
following command:
cat /sys/devices/system/cpu/vulnerabilities/l1tf
Warning:
Enabling L1TF mitigations may impact performance of the system. | Rationale: | The L1TF vulnerability allows an attacker to bypass memory access security controls imposed
by the system or hypervisor. The L1TF vulnerability allows read access to any physical memory
location that is cached in the L1 Data Cache. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_l1tf_argument | References: | | |
|
Rule
Force kernel panic on uncorrected MCEs
[ref] | A Machine Check Exception is an error generated by the CPU itdetects an error
in itself, memory or I/O devices.
These errors may be corrected and generate a check log entry, if an error
cannot be corrected the kernel may panic or SIGBUS.
To force the kernel to panic on any uncorrected error reported by Machine Check
set the MCE tolerance to zero by adding mce=0
to the default GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain mce=0 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) mce=0"
| Rationale: | Allowing uncorrected errors to result on a SIGBUS may allow an attacker to continue
trying to exploit a vulnerability such as Rowhammer. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_mce_argument | References: | | |
|
Rule
Configure Microarchitectural Data Sampling mitigation
[ref] | Microarchitectural Data Sampling (MDS) is a hardware vulnerability which allows unprivileged
speculative access to data which is available in various CPU internal buffers.
When performing store, load, L1 refill operations, processors write data into temporary
microarchitectural structures (buffers), and the data in the buffer can be forwarded to load
operations as an optimization.
Under certain conditions, data unrelated to the load operations can be speculatively
forwarded from the buffers to a disclosure gadget which allows in turn to infer the value
via a cache side channel attack.
Select the appropriate mitigation by adding the argument
mds=full,nosmt
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain mds= full,nosmt as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) mds=full,nosmt"
Not all processors are affected by all variants of MDS, but the mitigation mechanism is
identical for all of them.
Since Linux Kernel 5.2 you can check whether the system is vulnerable or mitigated with the
following command:
cat /sys/devices/system/cpu/vulnerabilities/mds
Warning:
Enabling MDS mitigations will impact performance of the system, mainly by workloads with
high rates of user-kernel-user space transitions. For example, system calls, NMIs and interrupts. | Rationale: | The MDS vulnerability allows an attacker to sample data from internal CPU buffers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_mds_argument | References: | | |
|
Rule
Ensure SMAP is not disabled during boot
[ref] | The SMAP is used to prevent the supervisor mode from unintentionally reading/writing into
memory pages in the user space, it is enabled by default since Linux kernel 3.7.
But it could be disabled through kernel boot parameters.
Ensure that Supervisor Mode Access Prevention (SMAP) is not disabled by
the nosmap boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument nosmap .
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmap"
| Rationale: | Disabling SMAP can facilitate exploitation of vulnerabilities caused by unintended access and
manipulation of data in the user space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_nosmap_argument_absent | References: | | |
|
Rule
Ensure SMEP is not disabled during boot
[ref] | The SMEP is used to prevent the supervisor mode from executing user space code,
it is enabled by default since Linux kernel 3.0. But it could be disabled through
kernel boot parameters.
Ensure that Supervisor Mode Execution Prevention (SMEP) is not disabled by
the nosmep boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument nosmep .
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmep"
| Rationale: | Disabling SMEP can facilitate exploitation of certain vulnerabilities because it allows
the kernel to unintentionally execute code in less privileged memory space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_nosmep_argument_absent | References: | | |
|
Rule
Enable randomization of the page allocator
[ref] | To enable randomization of the page allocator in the kernel, add the
page_alloc.shuffle=1 argument to the default GRUB 2 command line.
Configure the default Grub2 kernel command line to contain page_alloc.shuffle=1 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) page_alloc.shuffle=1"
| Rationale: | The CONFIG_SHUFFLE_PAGE_ALLOCATOR config option is primarily
focused on improving the average utilization of a direct-mapped
memory-side-cache. Aside of this performance effect, it also reduces
predictability of page allocations in situations when the bad actor can
crash the system and somehow leverage knowledge of (page) allocation order
right after a fresh reboot, or can control the timing between a
hot-pluggable memory node (as in NUMA node) and applications allocating
memory ouf of that node. The page_alloc.shuffle=1 kernel command
line parameter then forces this functionality irrespectively of memory cache
architecture. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_page_alloc_shuffle_argument | References: | | |
|
Rule
Enable Kernel Page-Table Isolation (KPTI)
[ref] | To enable Kernel page-table isolation,
add the argument pti=on to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain pti=on as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) pti=on"
| Rationale: | Kernel page-table isolation is a kernel feature that mitigates
the Meltdown security vulnerability and hardens the kernel
against attempts to bypass kernel address space layout
randomization (KASLR). | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_pti_argument | References: | | |
|
Rule
Configure the confidence in TPM for entropy
[ref] | The TPM security chip that is available in most modern systems has a hardware RNG.
It is also used to feed the entropy pool, but generally not credited entropy.
Use rng_core.default_quality in the kernel command line to set the trust
level on the hardware generators. The trust level defines the amount of entropy to credit.
A value of 0 tells the system not to trust the hardware random number generators
available, and doesn't credit any entropy to the pool.
A value of 1000 assigns full confidence in the generators, and credits all the
entropy it provides to the pool.
Note that the value of rng_core.default_quality is global, affecting the trust
on all hardware random number generators.
Select the appropriate confidence by adding the argument
rng_core.default_quality=500
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain rng_core.default_quality= 500 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) rng_core.default_quality=500"
| Rationale: | A system may struggle to initialize its entropy pool and end up starving. Crediting entropy
from the hardware number generators available in the system helps fill up the entropy pool. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_rng_core_default_quality_argument | References: | | |
|
Rule
Disable merging of slabs with similar size
[ref] | The kernel may merge similar slabs together to reduce overhead and increase
cache hotness of objects.
Disabling merging of slabs keeps the slabs separate and reduces the risk of
kernel heap overflows overwriting objects in merged caches.
To disable merging of slabs in the Kernel add the argument slab_nomerge=yes
to the default GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain slab_nomerge=yes as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) slab_nomerge=yes"
Warning:
Disabling merge of slabs will slightly increase kernel memory utilization. | Rationale: | Disabling the merge of slabs of similar sizes prevents the kernel from
merging a seemingly useless but vulnerable slab with a useful and valuable slab.
This increase the risk that a heap overflow could overwrite objects from merged caches,
with unmerged caches the heap overflow would only affect the objects in the same cache.
Overall, this reduces the kernel attack surface area by isolating slabs from each other. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_slab_nomerge_argument | References: | | |
|
Rule
Configure Speculative Store Bypass Mitigation
[ref] | Certain CPUs are vulnerable to an exploit against a common wide industry wide performance
optimization known as Speculative Store Bypass (SSB).
In such cases, recent stores to the same memory location cannot always be observed by later
loads during speculative execution. However, such stores are unlikely and thus they can be
detected prior to instruction retirement at the end of a particular speculation execution
window.
Since Linux Kernel 4.17 you can check the SSB mitigation state with the following command:
cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Select the appropriate SSB state by adding the argument
spec_store_bypass_disable=seccomp
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain spec_store_bypass_disable= seccomp as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) spec_store_bypass_disable=seccomp"
Warning:
Disabling Speculative Store Bypass may impact performance of the system. | Rationale: | In vulnerable processsors, the speculatively forwarded store can be used in a cache side channel
attack. An example of this is reading memory to which the attacker does not directly have access,
for example inside the sandboxed code. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_spec_store_bypass_disable_argument | References: | | |
|
Rule
Enforce Spectre v2 mitigation
[ref] | Spectre V2 is an indirect branch poisoning attack that can lead to data leakage.
An exploit for Spectre V2 tricks the indirect branch predictor into executing
code from a future indirect branch chosen by the attacker, even if the privilege
level is different.
Since Linux Kernel 4.15 you can check the Spectre V2 mitigation state with the following command:
cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Enforce the Spectre V2 mitigation by adding the argument
spectre_v2=on to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain spectre_v2=on as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) spectre_v2=on"
| Rationale: | The Spectre V2 vulnerability allows an attacker to read memory that he should not have
access to. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_spectre_v2_argument | References: | | |
|
Group
Kernel Configuration
Group contains 1 group and 67 rules |
[ref]
Contains rules that check the kernel configuration that was used to build it. |
Group
Kernel GCC plugin configuration
Group contains 5 rules |
[ref]
Contains rules that check the configuration of GCC plugins used by the compiler |
Rule
Generate some entropy during boot and runtime
[ref] | Instrument some kernel code to extract some entropy from both original and artificially created
program state. This will help especially embedded systems where there is little 'natural' source
of entropy normally.
This configuration is available from kernel 4.9, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_GCC_PLUGIN_LATENT_ENTROPY , run the following command:
grep CONFIG_GCC_PLUGIN_LATENT_ENTROPY /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. Warning:
Note that entropy extracted this way is not cryptographically secure! Warning:
There is a performance cost during the boot process (about 0.5%) and fork and irq processing. | Rationale: | This helps generate entropy during startup and is particularly relevant for devices with
inappropriate entropy sources. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_gcc_plugin_latent_entropy | References: | | |
|
Rule
Randomize layout of sensitive kernel structures
[ref] | Randomize at compile-time the layouts of structures that are entirely function pointers
(and have not been manually annotated with __no_randomize_layout), or structures that have
been explicitly marked with __randomize_layout.
This configuration is available from kernel 4.13, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_GCC_PLUGIN_RANDSTRUCT , run the following command:
grep CONFIG_GCC_PLUGIN_RANDSTRUCT /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Randomizing the layout of kernel data structures make it more difficult for an attacker to
know the location of sensitive data. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_gcc_plugin_randstruct | References: | | |
|
Rule
Poison kernel stack before returning from syscalls
[ref] | This option makes the kernel erase the kernel stack before returning from system calls.
This has the effect of leaving the stack initialized to the poison value, which both reduces
the lifetime of any sensitive stack contents and reduces potential for uninitialized stack
variable exploits or information exposures (it does not cover functions reaching the same
stack depth as prior functions during the same syscall).
This configuration is available from kernel 4.20, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_GCC_PLUGIN_STACKLEAK , run the following command:
grep CONFIG_GCC_PLUGIN_STACKLEAK /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. Warning:
The performance impact on a single CPU system kernel is of 1% slowdown. | Rationale: | This blocks most uninitialized stack variable attacks, with the performance impact being
driven by the depth of the stack usage, rather than the function calling complexity. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_gcc_plugin_stackleak | References: | | |
|
Rule
Force initialization of variables containing userspace addresses
[ref] | While the kernel is built with warnings enabled for any missed stack variable initializations,
this warning is silenced for anything passed by reference to another function, under the
occasionally misguided assumption that the function will do the initialization. As this
regularly leads to exploitable flaws, this plugin is available to identify and zero-initialize
such variables, depending on the chosen level of coverage.
This configuration is available from kernel 4.11, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_GCC_PLUGIN_STRUCTLEAK , run the following command:
grep CONFIG_GCC_PLUGIN_STRUCTLEAK /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Initializing structures from userspace can prevent some classes of information exposure. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_gcc_plugin_structleak | References: | | |
|
Rule
zero-init everything passed by reference
[ref] | Zero-initialize any stack variables that may be passed by reference and had not already been explicitly initialized.
This configuration is available from kernel 4.14, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL , run the following command:
grep CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This eliminates all classes of uninitialized stack variable exploits and information exposures. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_gcc_plugin_structleak_byref_all | References: | | |
|
Rule
Do not allow ACPI methods to be inserted/replaced at run time
[ref] | This debug facility allows ACPI AML methods to be inserted and/or replaced without rebooting
the system.
This configuration is available from kernel 3.0.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_ACPI_CUSTOM_METHOD , run the following command:
grep CONFIG_ACPI_CUSTOM_METHOD /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Enabling this feature allows arbitrary kernel memory to be written to by root (uid=0) users,
allowing them to bypass certain security measures | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_acpi_custom_method | References: | | |
|
Rule
Emulate Privileged Access Never (PAN)
[ref] | Enabling this option prevents the kernel from accessing user-space memory directly by pointing
TTBR0_EL1 to a reserved zeroed area and reserved ASID.
The user access routines restore the valid TTBR0_EL1 temporarily.
This configuration is available from kernel 4.10, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_ARM64_SW_TTBR0_PAN , run the following command:
grep CONFIG_ARM64_SW_TTBR0_PAN /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | The Privileged Access Never (PAN) is the ARM equivalent of the x86 Supervisor Mode Access
Prevention (SMAP), and it prevents privileged acccess to user data unless explicitly enabled. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_arm64_sw_ttbr0_pan | References: | | |
|
Rule
Disable kernel support for MISC binaries
[ref] | Enabling CONFIG_BINFMT_MISC makes it possible to plug wrapper-driven binary formats
into the kernel. This is specially useful for programs that need an interpreter to run like
Java, Python and DOS emulators. Once you have registered such a binary class with the kernel,
you can start one of those programs simply by typing in its name at a shell prompt.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_BINFMT_MISC , run the following command:
grep CONFIG_BINFMT_MISC /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This disables arbitrary binary format support and helps reduce attack surface. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_binfmt_misc | References: | | |
|
Rule
Enable support for BUG()
[ref] | Disabling this option eliminates support for BUG and WARN, reducing the size of your kernel
image and potentially quietly ignoring numerous fatal conditions. You should only consider
disabling this option for embedded systems with no facilities for reporting errors.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_BUG , run the following command:
grep CONFIG_BUG /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Not setting this variable may hide a number of critical errors. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_bug | References: | | |
|
Rule
Trigger a kernel BUG when data corruption is detected
[ref] | This option makes the kernel BUG when it encounters data corruption in kernel memory structures
when they get checked for validity.
This configuration is available from kernel 4.10.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_BUG_ON_DATA_CORRUPTION , run the following command:
grep CONFIG_BUG_ON_DATA_CORRUPTION /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This helps detect data corruptions early and stop with a BUG() error message. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_bug_on_data_corruption | References: | | |
|
Rule
Disable compatibility with brk()
[ref] | Enabling compatiliby with brk() allows legacy binaries to run (i.e. those linked
against libc5). But this compatibility comes at the cost of not being able to randomize
the heap placement (ASLR).
Unless legacy binaries need to run on the system, set CONFIG_COMPAT_BRK to "n" .
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_COMPAT_BRK , run the following command:
grep CONFIG_COMPAT_BRK /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Enabling compatibility with brk() disables support for ASLR. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_compat_brk | References: | | |
|
Rule
Disable the 32-bit vDSO
[ref] | Certain buggy versions of glibc (2.3.3) will crash if they are presented with a 32-bit vDSO
that is not mapped at the address indicated in its segment table.
Setting CONFIG_COMPAT_VDSO to y turns off the 32-bit VDSO and works
aroud the glibc bug.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_COMPAT_VDSO , run the following command:
grep CONFIG_COMPAT_VDSO /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Enabling VDSO compatibility hurts performance and disables ASLR. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_compat_vdso | References: | | |
|
Rule
Enable checks on credential management
[ref] | Enable this to turn on some debug checking for credential management. The additional code keeps
track of the number of pointers from task_structs to any given cred struct, and checks to see
that this number never exceeds the usage count of the cred struct.
Furthermore, if SELinux is enabled, this also checks that the security pointer in the cred
struct is never seen to be invalid.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEBUG_CREDENTIALS , run the following command:
grep CONFIG_DEBUG_CREDENTIALS /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This adds sanity checks and validations to credential data structures. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_debug_credentials | References: | | |
|
Rule
Disable kernel debugfs
[ref] | debugfs is a virtual file system that kernel developers use to put debugging files
into. Enable this option to be able to read and write to these files.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEBUG_FS , run the following command:
grep CONFIG_DEBUG_FS /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | To reduce the attack surface, this file system should be disabled if not in use. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_debug_fs | References: | | |
|
Rule
Enable checks on linked list manipulation
[ref] | Enable this to turn on extended checks in the linked-list walking routines.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEBUG_LIST , run the following command:
grep CONFIG_DEBUG_LIST /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This add sanity checks to manipulation of linked lists structures in the kernel and may
prevent exploits such as CVE-2017-1661, where a race condition and simultaneos operations
caused a list to corrupt. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_debug_list | References: | | |
|
Rule
Enable checks on notifier call chains
[ref] | Enable this to turn on sanity checking for notifier call chains. This is most useful for kernel
developers to make sure that modules properly unregister themselves from notifier chains.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEBUG_NOTIFIERS , run the following command:
grep CONFIG_DEBUG_NOTIFIERS /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This provides validation of notifier chains, it checks whether the notifiers are from the
kernel or a module that is still loaded prior to being invoked. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_debug_notifiers | References: | | |
|
Rule
Enable checks on scatter-gather (SG) table operations
[ref] | Scatter-gather tables are mechanism used for high performance I/O on DMA devices.
Enable this to turn on checks on scatter-gather tables.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEBUG_SG , run the following command:
grep CONFIG_DEBUG_SG /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This can help find problems with drivers that do not properly initialize their SG tables. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_debug_sg | References: | | |
|
Rule
Warn on W+X mappings found at boot
[ref] | Generate a warning if any W+X mappings are found at boot.
This configuration is available from kernel 5.8.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEBUG_WX , run the following command:
grep CONFIG_DEBUG_WX /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This is useful for discovering cases where the kernel is leaving W+X mappings after applying NX,
as such mappings are a security risk.
Note that even if the check fails, your kernel is possibly still fine, as W+X mappings are not
a security hole in themselves, what they do is that they make the exploitation of other unfixed
kernel bugs easier. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_debug_wx | References: | | |
|
Rule
Configure Low Address Space To Protect From User Allocation
[ref] | This is the portion of low virtual memory which should be protected from userspace allocation.
This configuration is available from kernel 3.14, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEFAULT_MMAP_MIN_ADDR , run the following command:
grep CONFIG_DEFAULT_MMAP_MIN_ADDR /boot/config-*
For each kernel installed, a line with value should be returned.
If the system architecture is x86_64, the value should be 65536.
If the system architecture is aarch64, the value should be 32768. Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_default_mmap_min_addr | References: | | |
|
Rule
Disable /dev/kmem virtual device support
[ref] | Disable support for the /dev/kmem device.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_DEVKMEM , run the following command:
grep CONFIG_DEVKMEM /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | The /dev/kmem device is rarely used, but can be used for certain kind of kernel debugging
operations. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_devkmem | References: | | |
|
Rule
Harden common str/mem functions against buffer overflows
[ref] | Detect overflows of buffers in common string and memory functions where the compiler can
determine and validate the buffer sizes.
This configuration is available from kernel 4.13, but may be available if backported by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_FORTIFY_SOURCE , run the following command:
grep CONFIG_FORTIFY_SOURCE /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This features helps reduce likelihood of memory corruption of kernel structures. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_fortify_source | References: | | |
|
Rule
Harden memory copies between kernel and userspace
[ref] | This option checks for obviously wrong memory regions when copying memory to/from the kernel
(via copy_to_user() and copy_from_user() functions) by rejecting memory ranges that are larger
than the specified heap object, span multiple separately allocated pages, are not on the
process stack, or are part of the kernel text.
This configuration is available from kernel 4.8, and may be available if backported by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_HARDENED_USERCOPY , run the following command:
grep CONFIG_HARDENED_USERCOPY /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This config prevents entire classes of heap overflow exploits and similar kernel memory exposures.
| Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_hardened_usercopy | References: | | |
|
Rule
Do not allow usercopy whitelist violations to fallback to object size
[ref] | This is a temporary option that allows missing usercopy whitelists to be discovered via a WARN()
to the kernel log, instead of rejecting the copy, falling back to non-whitelisted hardened
usercopy that checks the slab allocation size instead of the whitelist size.
This configuration is available from kernel 4.16.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_HARDENED_USERCOPY_FALLBACK , run the following command:
grep CONFIG_HARDENED_USERCOPY_FALLBACK /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This config prevents entire classes of heap overflow exploits and similar kernel memory exposures. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_hardened_usercopy_fallback | References: | | |
|
Rule
Disable hibernation
[ref] | Enable the suspend to disk (STD) functionality, which is usually called "hibernation" in user
interfaces. STD checkpoints the system and powers it off; and restores that checkpoint on
reboot.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_HIBERNATION , run the following command:
grep CONFIG_HIBERNATION /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Suspending to disk allows one to replace the running kernel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_hibernation | References: | | |
|
Rule
Disable IA32 emulation
[ref] | Disables support for legacy 32-bit programs under a 64-bit kernel.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_IA32_EMULATION , run the following command:
grep CONFIG_IA32_EMULATION /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. Warning:
Only disable support for 32-bit programs if you are sure you don't need any 32-bit program. | Rationale: | Disabling 32-bit backwards compatibility helps reduce the attack surface. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_ia32_emulation | References: | | |
|
Rule
Disable kexec system call
[ref] | kexec is a system call that implements the ability to shutdown your current kernel,
and to start another kernel. It is like a reboot but it is independent of the system firmware.
And like a reboot you can start any kernel with it, not just Linux.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_KEXEC , run the following command:
grep CONFIG_KEXEC /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Prohibits the execution of a new kernel image after reboot. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_kexec | References: | | |
|
Rule
Disable legacy (BSD) PTY support
[ref] | Disable the Linux traditional BSD-like terminal names /dev/ptyxx for masters and /dev/ttyxx for
slaves of pseudo terminals, and use only the modern ptys (devpts) interface.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_LEGACY_PTYS , run the following command:
grep CONFIG_LEGACY_PTYS /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | The legacy scheme has a number of security problems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_legacy_ptys | References: | | |
|
Rule
Disable vsyscall emulation
[ref] | The kernel traps and emulates calls into the fixed vsyscall address mapping.
This configuration is available from kernel 5.3, but may be available if backported by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_LEGACY_VSYSCALL_EMULATE , run the following command:
grep CONFIG_LEGACY_VSYSCALL_EMULATE /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | The mapping is non-executable, but it still contains known contents, which could be
used in certain rare security vulnerability exploits. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_legacy_vsyscall_emulate | References: | | |
|
Rule
Disable vsyscall mapping
[ref] | This config disables the vsyscall mapping at all. Attempts to use the vsyscalls will be reported to
dmesg, so that either old or malicious userspace programs can be identified.
This configuration is available from kernel 4.4.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_LEGACY_VSYSCALL_NONE , run the following command:
grep CONFIG_LEGACY_VSYSCALL_NONE /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This will eliminate any risk of ASLR bypass due to the vsyscall fixed address mapping. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_legacy_vsyscall_none | References: | | |
|
Rule
Disable vsyscall emulate execution only
[ref] | The kernel traps and emulates calls into the fixed vsyscall address mapping and does not allow
reads.
This configuration is available from kernel 5.3.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_LEGACY_VSYSCALL_XONLY , run the following command:
grep CONFIG_LEGACY_VSYSCALL_XONLY /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Disabling this mitigates certain uses of the vsyscall area as an ASLR-bypassing buffer. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_legacy_vsyscall_xonly | References: | | |
|
Rule
Disable the LDT (local descriptor table)
[ref] | Linux can allow user programs to install a per-process x86 Local Descriptor Table (LDT) using
the modify_ldt(2) system call. This is required to run 16-bit or segmented code such as DOSEMU
or some Wine programs. It is also used by some very old threading libraries.
This configuration is available from kernel 4.3, but may be available if backported
by distros.
Disable LDT if 16-bit program emulation is not necessary.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODIFY_LDT_SYSCALL , run the following command:
grep CONFIG_MODIFY_LDT_SYSCALL /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Disabling support for unnecessary code reduces attack surface. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_modify_ldt_syscall | References: | | |
|
Rule
Enable module signature verification
[ref] | Check modules for valid signatures upon load.
Note that this option adds the OpenSSL development packages as a kernel build dependency so
that the signing tool can use its crypto library.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODULE_SIG , run the following command:
grep CONFIG_MODULE_SIG /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Loaded modules must be signed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_module_sig | References: | | |
|
Rule
Enable automatic signing of all modules
[ref] | Sign all modules during make modules_install. Without this option, modules must be signed
manually, using the scripts/sign-file tool.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODULE_SIG_ALL , run the following command:
grep CONFIG_MODULE_SIG_ALL /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This ensures the modules are signed during install process. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_module_sig_all | References: | | |
|
Rule
Require modules to be validly signed
[ref] | Reject unsigned modules or signed modules with an unknown key.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODULE_SIG_FORCE , run the following command:
grep CONFIG_MODULE_SIG_FORCE /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Prevent loading modules that are unsigned or signed with an unknown key. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_module_sig_force | References: | | |
|
Rule
Specify the hash to use when signing modules
[ref] | This configures the kernel to build and sign modules using
sha512 as the hash function.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODULE_SIG_HASH , run the following command:
grep CONFIG_MODULE_SIG_HASH /boot/config-*
For each kernel installed, a line with value " sha512" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Use of strong hash function is important to secure the module against counterfeit signatures. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_module_sig_hash | References: | | |
|
Rule
Specify module signing key to use
[ref] | Setting this option to something other than its default of certs/signing_key.pem will
disable the autogeneration of signing keys and allow the kernel modules to be signed with a key
of your choosing.
The string provided should identify a file containing both a private key and
its corresponding X.509 certificate in PEM form, or — on systems where the OpenSSL ENGINE_pkcs11
is functional — a PKCS#11 URI as defined by RFC7512. In the latter case, the PKCS#11 URI should
reference both a certificate and a private key.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODULE_SIG_KEY , run the following command:
grep CONFIG_MODULE_SIG_KEY /boot/config-*
For each kernel installed, a line with value " certs/signing_key.pem" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | A key and certificate is required to sign the built modules. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_module_sig_key | References: | | |
|
Rule
Sign kernel modules with SHA-512
[ref] | This configures the kernel to build and sign modules using SHA512 as the hash function.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_MODULE_SIG_SHA512 , run the following command:
grep CONFIG_MODULE_SIG_SHA512 /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Use of strong hash function is important to secure the module against counterfeit signatures. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_module_sig_sha512 | References: | | |
|
Rule
Enable poison of pages after freeing
[ref] | Fill the pages with poison patterns after free_pages() and verify the patterns before
alloc_pages. This does have a potential performance impact if enabled with the "page_poison=1"
kernel boot option.
This configuration is available from kernel 4.6.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PAGE_POISONING , run the following command:
grep CONFIG_PAGE_POISONING /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | The filling of the memory helps reduce the risk of information leaks from freed data. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_page_poisoning | References: | | |
|
Rule
Enable poison without sanity check
[ref] | Skip the sanity checking on alloc, only fill the pages with poison on free. This reduces some
of the overhead of the poisoning feature.
This configuration is available from kernel 4.6.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PAGE_POISONING_NO_SANITY , run the following command:
grep CONFIG_PAGE_POISONING_NO_SANITY /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This configuration helps alleviates the performance impact of poisonining. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_page_poisoning_no_sanity | References: | | |
|
Rule
Use zero for poisoning instead of debugging value
[ref] | Instead of using the existing poison value, fill the pages with zeros. This makes it harder to
detect when errors are occurring due to sanitization but the zeroing at free means that it is
no longer necessary to write zeros when GFP_ZERO is used on allocation.
This configuration is available from kernel 4.19.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PAGE_POISONING_ZERO , run the following command:
grep CONFIG_PAGE_POISONING_ZERO /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This configuration helps alleviates the performance impact of poisonining. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_page_poisoning_zero | References: | | |
|
Rule
Remove the kernel mapping in user mode
[ref] | This feature reduces the number of hardware side channels by ensuring that the majority of
kernel addresses are not mapped into userspace.
This configuration is available from kernel 4.15, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PAGE_TABLE_ISOLATION , run the following command:
grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This is a countermeasure to the Meltdown attack. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_page_table_isolation | References: | | |
|
Rule
Kernel panic oops
[ref] | Enable the kernel to panic when it oopses.
This has the same effect as setting oops=panic on the kernel command line.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PANIC_ON_OOPS , run the following command:
grep CONFIG_PANIC_ON_OOPS /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This feature ensures that the kernel does not do anything erroneous after an oops which
could result in data corruption or other issues. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_panic_on_oops | References: | | |
|
Rule
Kernel panic timeout
[ref] | Set the timeout value (in seconds) until a reboot occurs when the kernel panics.
A timeout of 0 configures the system to wait forever. With a timeout value greater than 0,
the system will wait the specified amount of seconds before rebooting. While a timeout value
less than 0 makes the system reboot immediately.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PANIC_TIMEOUT , run the following command:
grep CONFIG_PANIC_TIMEOUT /boot/config-*
For each kernel installed, a line with value " 0" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This is required to enable protection against Spectre v2. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_panic_timeout | References: | | |
|
Rule
Disable support for /proc/kkcore
[ref] | Provides a virtual ELF core file of the live kernel.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_PROC_KCORE , run the following command:
grep CONFIG_PROC_KCORE /boot/config-*
Configs with value 'n' are not explicitly set in the file, so either commented lines or no
lines should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This feature exposes the memory to the userspace and can assist an attacker in discovering
attack vectors. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_proc_kcore | References: | | |
|
Rule
Randomize the address of the kernel image (KASLR)
[ref] | In support of Kernel Address Space Layout Randomization (KASLR), this randomizes the physical
address at which the kernel image is decompressed and the virtual address where the kernel
image is mapped.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_RANDOMIZE_BASE , run the following command:
grep CONFIG_RANDOMIZE_BASE /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | An unpredictable kernel address makes it more difficult to succeed with exploits that rely on
knowledge of the location of kernel code internals. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_randomize_base | References: | | |
|
Rule
Randomize the kernel memory sections
[ref] | Randomizes the base virtual address of kernel memory sections (physical memory mapping,
vmalloc & vmemmap).
This configuration is available from kernel 4.8, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_RANDOMIZE_MEMORY , run the following command:
grep CONFIG_RANDOMIZE_MEMORY /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This security feature makes exploits relying on predictable memory locations less reliable. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_randomize_memory | References: | | |
|
Rule
Perform full reference count validation
[ref] | Enabling this switches the refcounting infrastructure from a fast unchecked atomic_t
implementation to a fully state checked implementation, which can have a slight
impact in performance.
This configuration is available from kernel 4.13, but may be available if backported
by distros.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_REFCOUNT_FULL , run the following command:
grep CONFIG_REFCOUNT_FULL /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | Refcounting provides protections against various use-after-free conditions that can be
used in security flaw exploits. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_refcount_full | References: | | |
|
Rule
Avoid speculative indirect branches in kernel
[ref] | Compile kernel with the retpoline compiler options to guard against kernel-to-user data leaks
by avoiding speculative indirect branches.
Requires a compiler with -mindirect-branch=thunk-extern support for full protection.
The kernel may run slower.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_RETPOLINE , run the following command:
grep CONFIG_RETPOLINE /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This is required to enable protection against Spectre v2. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_retpoline | References: | | |
|
Rule
Detect stack corruption on calls to schedule()
[ref] | This option checks for a stack overrun on calls to schedule(). If the stack end location is
found to be overwritten always panic as the content of the corrupted region can no longer
be trusted.
This configuration is available from kernel 3.18.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_SCHED_STACK_END_CHECK , run the following command:
grep CONFIG_SCHED_STACK_END_CHECK /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | Rationale: | This ensures no erroneous behaviour occurs which could result in data corruption or a
sporadic crash at a later stage once the region is examined. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_config_sched_stack_end_check | References: | | |
|
Rule
Enable seccomp to safely compute untrusted bytecode
[ref] | This kernel feature is useful for number crunching applications that may need to compute
untrusted bytecode during their execution. By using pipes or other transports made available
to the process as file descriptors supporting the read/write syscalls, it's possible to isolate
those applications in their own address space using seccomp.
The configuration that was used to build kernel is available at /boot/config-* .
To check the configuration value for CONFIG_SECCOMP , run the following command:
grep CONFIG_SECCOMP /boot/config-*
For each kernel installed, a line with value "y" should be returned.
Warning:
There is no remediation for this besides re-compiling the kernel with the appropriate value for the config. | |
|