To enable Kernel page-table isolation, add the argument pti=on to all BLS (Boot Loader Specification) entries ('options' line) for the Linux operating system in /boot/loader/entries/*.conf.
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).
To disable use of virtual syscalls, add the argument vsyscall=none to all BLS (Boot Loader Specification) entries ('options' line) for the Linux operating system in /boot/loader/entries/*.conf.
Virtual Syscalls provide an opportunity of attack for a user who has control of the return instruction pointer.
The file /boot/efi/EFI/redhat/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/efi/EFI/redhat/grub.cfg, run the command:
$ sudo chgrp root /boot/efi/EFI/redhat/grub.cfg
The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.
The file /boot/efi/EFI/redhat/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/efi/EFI/redhat/user.cfg, run the command:
$ sudo chgrp root /boot/efi/EFI/redhat/user.cfg
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.
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
The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.
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
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.
The file /boot/efi/EFI/redhat/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/efi/EFI/redhat/grub.cfg, run the command:
$ sudo chown root /boot/efi/EFI/redhat/grub.cfg
Only root should be able to modify important boot parameters.
The file /boot/efi/EFI/redhat/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/efi/EFI/redhat/user.cfg, run the command:
$ sudo chown root /boot/efi/EFI/redhat/user.cfg
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.
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
Only root should be able to modify important boot parameters.
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
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.
File permissions for /boot/efi/EFI/redhat/grub.cfg should be set to 700.
To properly set the permissions of /boot/efi/EFI/redhat/grub.cfg, run the command:
$ sudo chmod 700 /boot/efi/EFI/redhat/grub.cfg
Proper permissions ensure that only the root user can modify important boot parameters.
File permissions for /boot/efi/EFI/redhat/user.cfg should be set to 600.
To properly set the permissions of /boot/efi/EFI/redhat/user.cfg, run the command:
$ sudo chmod 600 /boot/efi/EFI/redhat/user.cfg
Proper permissions ensure that only the root user can read or modify important boot parameters.
File permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg, run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
Proper permissions ensure that only the root user can modify important boot parameters.
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
Proper permissions ensure that only the root user can read or modify important boot parameters.
The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
To maximize the protection, select a password-protected superuser account with unique name, and modify the
/etc/grub.d/01_users configuration file to reflect the account name change.
Do not to use common administrator account names like root,
admin, or administrator for the grub2 superuser account.
Change the superuser to a different username (The default is 'root').
$ sed -i 's/\(set superusers=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users
grubby --update-kernel=ALL --env=/boot/grub2/grubenv
Having a non-default grub superuser username makes password-guessing attacks less effective.
To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system. To ensure that audit=1 is added as a kernel command line argument to newly installed kernels, add audit=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... audit=1 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="audit=1"
Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot.
To improve the kernel capacity to queue all log events, even those which occurred prior to the audit daemon, add the argument audit_backlog_limit=8192 to the default GRUB 2 command line for the Linux operating system. To ensure that audit_backlog_limit=8192 is added as a kernel command line argument to newly installed kernels, add audit_backlog_limit=8192 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"
audit_backlog_limit sets the queue length for audit events awaiting transfer to the audit daemon. Until the audit daemon is up and running, all log messages are stored in this queue. If the queue is overrun during boot process, the action defined by audit failure flag is taken.
Red Hat Enterprise Linux 8 systems support an "interactive boot" option that can be used to prevent services from being started. On a Red Hat Enterprise Linux 8 system, interactive boot can be enabled by providing a 1, yes, true, or on value to the systemd.confirm_spawn kernel argument in /etc/default/grub. Remove any instance of
systemd.confirm_spawn=(1|yes|true|on)from the kernel arguments in that file to disable interactive boot. Recovery booting must also be disabled. Confirm that GRUB_DISABLE_RECOVERY=true is set in /etc/default/grub. It is also required to change the runtime configuration, run:
/sbin/grubby --update-kernel=ALL --remove-args="systemd.confirm_spawn"
grub2-mkconfig -o /boot/grub2/grub.cfg
Using interactive or recovery boot, the console user could disable auditing, firewalls, or other services, weakening system security.
Red Hat Enterprise Linux 8 systems support an "recovery boot" option that can be used to prevent services from being started. The GRUB_DISABLE_RECOVERY configuration option in /etc/default/grub should be set to true to disable the generation of recovery mode menu entries. It is also required to change the runtime configuration, run:
$ sudo grubby --update-kernel=ALL --env=/boot/grub2/grubenv
Using recovery boot, the console user could disable auditing, firewalls, or other services, weakening system security.
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.
AppArmor must be enabled at boot time in your bootloader configuration to ensure that the controls it provides are not overridden.
To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips dracut -fAfter the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -ocommand as follows:
~]# grub2-mkconfig -o /boot/grub2/grub.cfg
~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
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. To ensure that iommu=force is added as a kernel command line argument to newly installed kernels, add iommu=force to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... iommu=force ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="iommu=force"
On x86 architectures, activating the I/OMMU prevents the system from arbitrary accesses potentially made by hardware devices.
SELinux can be disabled at boot time by an argument in /etc/default/grub. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot.
Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation.
To configure the kernel to zero out memory before allocating it, add the init_on_alloc=1 argument to the default GRUB 2 command line. To ensure that init_on_alloc=1 is added as a kernel command line argument to newly installed kernels, add init_on_alloc=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... init_on_alloc=1 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="init_on_alloc=1"
When the kernel configuration option init_on_alloc is enabled, all page allocator and slab allocator memory will be zeroed when allocated, eliminating many kinds of "uninitialized heap memory" flaws, effectively preventing data leaks.
To disable IPv6 protocol support in the Linux kernel, add the argument ipv6.disable=1 to the default GRUB2 command line for the Linux operating system. To ensure that ipv6.disable=1 is added as a kernel command line argument to newly installed kernels, add ipv6.disable=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... ipv6.disable=1 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="ipv6.disable=1"
Any unnecessary network stacks, including IPv6, should be disabled to reduce the vulnerability to exploitation.
There exist two ways how to ensure that the Linux kernel trusts the CPU hardware random number generator. If the option is configured during kernel compilation, e.g. the option CONFIG_RANDOM_TRUST_CPU is set to Y, make sure that it is not overridden with the boot parameter. There must not exist the boot parameter random.trust_cpu=off. If the option is not compiled in, make sure that random.trust_cpu=on is configured as a boot parameter. To ensure that random.trust_cpu=on is added as a kernel command line argument to newly installed kernels, add random.trust_cpu=on to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... random.trust_cpu=on ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="random.trust_cpu=on"
The Linux kernel offers an option which signifies if the kernel should trust data provided by CPU hardware random number generator. Hardware random number generators can provide random data very quickly and are used to generate random cryptographic keys. They can be useful during boot time when other means of getting random data can be slow because there is not yet enough entropy in the system.
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=$var_l1tf_options to the default GRUB 2 command line for the Linux operating system. To ensure that l1tf=$var_l1tf_options is added as a kernel command line argument to newly installed kernels, add l1tf=$var_l1tf_options to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... l1tf=$var_l1tf_options ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="l1tf=$var_l1tf_options"Since Linux Kernel 4.19 you can check the L1TF vulnerability state with the following command: cat /sys/devices/system/cpu/vulnerabilities/l1tf
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.
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. To ensure that mce=0 is added as a kernel command line argument to newly installed kernels, add mce=0 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... mce=0 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="mce=0"
Allowing uncorrected errors to result on a SIGBUS may allow an attacker to continue trying to exploit a vulnerability such as Rowhammer.
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=$var_mds_options to the default GRUB 2 command line for the Linux operating system. To ensure that mds=$var_mds_options is added as a kernel command line argument to newly installed kernels, add mds=$var_mds_options to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... mds=$var_mds_options ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="mds=$var_mds_options"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
The MDS vulnerability allows an attacker to sample data from internal CPU buffers.
Verify that Meltdown mitigations are not disabled:
$ sudo grubby --info=ALL | grep mitigationsThe mitigations must not be set to "off".
Hardware vulnerabilities allow programs to steal data that is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to obtain secrets stored in the memory of other running programs. This might include passwords stored in a password manager or browser; personal photos, emails, and instant messages; and business-critical documents.
The system must not allow removable media to be used as the boot loader. Remove alternate methods of booting the system from removable media. usb0, cd, fd0, etc. are some examples of removeable media which should not exist in the lines:
set root='hd0,msdos1'
Malicious users with removable boot media can gain access to a system configured to use removable media as the boot loader.
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"
Disabling SMAP can facilitate exploitation of vulnerabilities caused by unintended access and manipulation of data in the user space.
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"
Disabling SMEP can facilitate exploitation of certain vulnerabilities because it allows the kernel to unintentionally execute code in less privileged memory space.
All USB support can be disabled by adding the nousb argument to the kernel's boot loader configuration. To do so, append "nousb" to the kernel line in /etc/default/grub as shown:
kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb
Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems.
To enable randomization of the page allocator in the kernel, add the page_alloc.shuffle=1 argument to the default GRUB 2 command line. To ensure that page_alloc.shuffle=1 is added as a kernel command line argument to newly installed kernels, add page_alloc.shuffle=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... page_alloc.shuffle=1 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="page_alloc.shuffle=1"
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.
To enable poisoning of free pages, add the argument page_poison=1 to the default GRUB 2 command line for the Linux operating system. To ensure that page_poison=1 is added as a kernel command line argument to newly installed kernels, add page_poison=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... page_poison=1 ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="page_poison=1"
Poisoning writes an arbitrary value to freed pages, so any modification or reference to that page after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory.
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-setpasswordWhen prompted, enter the password that was selected.
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.
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 an encrypted grub2 password
for the grub superusers with the following command:
$ grub2-mkpasswd-pbkdf2When prompted, enter the password that was selected.
set superusers="root" password_pbkdf2 root grub.pbkdf2.sha512.VeryLongStringOnce the superuser password has been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfg
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.
To enable Kernel page-table isolation, add the argument pti=on to the default GRUB 2 command line for the Linux operating system. To ensure that pti=on is added as a kernel command line argument to newly installed kernels, add pti=on to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... pti=on ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="pti=on"
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).
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=$var_rng_core_default_quality to the default GRUB 2 command line for the Linux operating system. To ensure that rng_core.default_quality=$var_rng_core_default_quality is added as a kernel command line argument to newly installed kernels, add rng_core.default_quality=$var_rng_core_default_quality to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... rng_core.default_quality=$var_rng_core_default_quality ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="rng_core.default_quality=$var_rng_core_default_quality"
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.
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. To ensure that slab_nomerge=yes is added as a kernel command line argument to newly installed kernels, add slab_nomerge=yes to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... slab_nomerge=yes ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="slab_nomerge=yes"
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.
To enable poisoning of SLUB/SLAB objects, add the argument slub_debug=$var_slub_debug_options to the default GRUB 2 command line for the Linux operating system. To ensure that slub_debug=$var_slub_debug_options is added as a kernel command line argument to newly installed kernels, add slub_debug=$var_slub_debug_options to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... slub_debug=$var_slub_debug_options ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="slub_debug=$var_slub_debug_options"
Poisoning writes an arbitrary value to freed objects, so any modification or reference to that object after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory.
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=$var_spec_store_bypass_disable_options to the default GRUB 2 command line for the Linux operating system. To ensure that spec_store_bypass_disable=$var_spec_store_bypass_disable_options is added as a kernel command line argument to newly installed kernels, add spec_store_bypass_disable=$var_spec_store_bypass_disable_options to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... spec_store_bypass_disable=$var_spec_store_bypass_disable_options ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="spec_store_bypass_disable=$var_spec_store_bypass_disable_options"
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.
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. To ensure that spectre_v2=on is added as a kernel command line argument to newly installed kernels, add spectre_v2=on to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... spectre_v2=on ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="spectre_v2=on"
The Spectre V2 vulnerability allows an attacker to read memory that he should not have access to.
systemd's debug-shell service is intended to
diagnose systemd related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9. The debug-shell service should only be used
for systemd related issues and should otherwise be disabled.
By default, the debug-shell systemd service is already disabled.
Ensure the debug-shell is not enabled by the systemd.debug-shel=1
boot paramenter option.
Check that the line
GRUB_CMDLINE_LINUX="..."within /etc/default/grub doesn't contain the argument systemd.debug-shell=1. Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="systemd.debug-shell"
This prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted.
The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
To maximize the protection, select a password-protected superuser account with unique name, and modify the
/etc/grub.d/01_users configuration file to reflect the account name change.
It is highly suggested not to use common administrator account names like root,
admin, or administrator for the grub2 superuser account.
Change the superuser to a different username (The default is 'root').
$ sed -i 's/\(set superusers=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users
grubby --update-kernel=ALL --env=/boot/grub2/grubenv
Having a non-default grub superuser username makes password-guessing attacks less effective.
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-setpasswordWhen prompted, enter the password that was selected.
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.
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-mkpasswd-pbkdf2When prompted, enter the password that was selected.
set superusers="root" password_pbkdf2 boot grub.pbkdf2.sha512.VeryLongStringOnce the superuser password has been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
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.
To disable use of virtual syscalls, add the argument vsyscall=none to the default GRUB 2 command line for the Linux operating system. To ensure that vsyscall=none is added as a kernel command line argument to newly installed kernels, add vsyscall=none to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... vsyscall=none ..."Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="vsyscall=none"
Virtual Syscalls provide an opportunity of attack for a user who has control of the return instruction pointer.
The system must not allow removable media to be used as the boot loader. Remove alternate methods of booting the system from removable media. usb0, cd, fd0, etc. are some examples of removeable media which should not exist in the lines:
set root='hd0,msdos1'
Malicious users with removable boot media can gain access to a system configured to use removable media as the boot loader.