Update bootlaoder STIG content

linux_os/guide/system/bootloader-grub2/grub2_pti_argument/policy/stig/shared.yml

@@ -32,3 +32,6 @@ fixtext: |-
     Add or modify the following line in "/etc/default/grub" to ensure the configuration survives kernel updates:
 
     GRUB_CMDLINE_LINUX="pti=on"
+
+vuln_discussion: |-
+    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).

linux_os/guide/system/bootloader-grub2/grub2_vsyscall_argument/policy/stig/shared.yml

@@ -1,31 +1,36 @@
 srg_requirement: |-
-    {{{ full_name }}} must disable virtual syscalls.
+    {{{ full_name }}} must disable virtual system calls.
 
 vuldiscussion: |-
     Syscalls are special routines in the Linux kernel, which userspace applications ask to do privileged tasks.  Invoking a system call is an expensive operation because the processor must interrupt the currently executing task and switch context to kernel mode and then back to userspace after the system call completes.  Virtual Syscalls map into user space a page that contains some variables and the implementation of some system calls.  This allows the system calls to be executed in userspace to alleviate the context switching expense.
 
     Virtual Syscalls provide an opportunity of attack for a user who has control of the return instruction pointer.  Disabling vsyscalls help to prevent return oriented programming (ROP) attacks via buffer overflows and overruns. If the system intends to run containers based on RHEL 6 components, then virtual syscalls will need enabled so the components function properly.
 
 checktext: |-
-    Verify the current GRUB 2 configuration disables vsyscalls with the following command:
+    Verify the current GRUB 2 configuration disables virtual system calls with the following command:
 
     $ sudo grubby --info=ALL | grep args | grep -v 'vsyscall=none'
 
     If any output is returned, this is a finding.
 
-    Check that vsyscalls are disabled by default to persist in kernel updates with the following command:
+    Check that virtual system calls are disabled by default to persist in kernel updates with the following command:
 
     $ sudo grep vsyscall /etc/default/grub
 
     GRUB_CMDLINE_LINUX="vsyscall=none"
 
-    If "vsyscall" is not set to "none", is missing or commented out and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.
+    If "vsyscall" is not set to "none", is missing or commented out, and is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding.
 
 fixtext: |-
-    Document the use of vsyscalls with the ISSO as an operational requirement or disable them with the following command:
+    Document the use of virtual system calls with the ISSO as an operational requirement or disable them with the following command:
 
     $ sudo grubby --update-kernel=ALL --args="vsyscall=none"
 
     Add or modify the following line in "/etc/default/grub" to ensure the configuration survives kernel updates:
 
     GRUB_CMDLINE_LINUX="vsyscall=none"
+
+vuln_discussion: |-
+    System calls are special routines in the Linux kernel, which userspace applications ask to do privileged tasks. Invoking a system call is an expensive operation because the processor must interrupt the currently executing task and switch context to kernel mode and then back to userspace after the system call completes. Virtual system calls map into user space a page that contains some variables and the implementation of some system calls. This allows the system calls to be executed in userspace to alleviate the context switching expense.
+
+    Virtual system calls provide an opportunity of attack for a user who has control of the return instruction pointer. Disabling virtual system calls help to prevent return oriented programming (ROP) attacks via buffer overflows and overruns. If the system intends to run containers based on RHEL 6 components, then virtual system calls will need enabled so the components function properly.

linux_os/guide/system/bootloader-grub2/non-uefi/file_groupowner_grub2_cfg/policy/stig/shared.yml

@@ -1,5 +1,5 @@
 srg_requirement: |-
-    The {{{ full_name }}} /boot/grub2/grub.cfg file must be group-owned by root.
+    {{{ full_name }}} /boot/grub2/grub.cfg file must be group-owned by root.
 
 vuldiscussion: |-
     The "root" group is a highly-privileged group. Furthermore, the group-owner of this
@@ -18,3 +18,6 @@ fixtext: |-
     Change the group of the file /boot/grub2/grub.cfg to root by running the following command:
 
     $ sudo chgrp root /boot/grub2/grub.cfg
+
+vuln_discussion: |-
+    The "root" group is a highly privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.

linux_os/guide/system/bootloader-grub2/non-uefi/file_owner_grub2_cfg/policy/stig/shared.yml

@@ -0,0 +1,19 @@
+srg_requirement: |-
+    {{{ full_name }}} /boot/grub2/grub.cfg file must be owned by root.
+
+fixtext: |-
+    Change the owner of the file /boot/grub2/grub.cfg to root by running the following command:
+
+    $ sudo chown root /boot/grub2/grub.cfg
+
+checktext: |-
+    Verify the ownership of the "/boot/grub2/grub.cfg" file with the following command:
+
+    $ sudo stat -c "%U %n" /boot/grub2/grub.cfg
+
+    root /boot/grub2/grub.cfg
+
+    If "/boot/grub2/grub.cfg" file does not have an owner of "root", this is a finding.
+
+vuln_discussion: |-
+    The " /boot/grub2/grub.cfg" file stores sensitive system configuration. Protection of this file is critical for system security.

linux_os/guide/system/bootloader-grub2/non-uefi/grub2_admin_username/policy/stig/shared.yml

@@ -9,11 +9,10 @@ checktext: |-
 
     $ sudo grep -A1 "superusers" /etc/grub2.cfg
 
-     set superusers="<superusers-account>"
+    set superusers="&ltsuperusers-account&gt"
     export superusers
 
-    The <superusers-account> is the actual account name different from common names like root,
-    admin, or administrator.
+    The &ltsuperusers-account&gt is the actual account name different from common names like root, admin, or administrator.
 
     If superusers contains easily guessable usernames, this is a finding.
 
@@ -27,4 +26,7 @@ fixtext: |-
 
     Once the superuser account has been added, update the grub.cfg file by running:
 
-    $ sudo grubby --update-kernel=ALL'
+    $ sudo grubby --update-kernel=ALL
+
+vuln_discussion: |-
+    Having a nondefault grub superuser username makes password-guessing attacks less effective.

linux_os/guide/system/bootloader-grub2/non-uefi/grub2_password/policy/stig/shared.yml

@@ -8,15 +8,13 @@ vuldiscussion: |-
     important bootloader settings. These include which kernel to use, and whether to enter single-user mode.
 
 checktext: |-
-    Verify the boot loader superuser password has been set, run the following
-    command:
+    Verify the boot loader superuser password has been set and run the following command:
 
-    $sudo grep "superusers" /etc/grub2.cfg
+    $ sudo grep "superusers" /etc/grub2.cfg
 
     password_pbkdf2  superusers-account   ${GRUB2_PASSWORD}
 
-    To verify the boot loader superuser account password has been set,
-    and the password encrypted, run the following command:
+    To verify the boot loader superuser account password has been set, and the password encrypted, run the following command:
 
     $ sudo cat /boot/grub2/user.cfg
 
@@ -35,3 +33,8 @@ fixtext: |-
     $ sudo grub2-setpassword
     Enter password:
     Confirm password:
+
+vuln_discussion: |-
+    To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DOD-approved PKIs, all DOD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.
+
+    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.