Canonical Ubuntu 18.04 LTS Security Technical Implementation Guide

Checks: C-20874r304775_chk

Verify the Ubuntu operating system enables auditing at system startup. Check that the auditing is enabled in grub with the following command: grep "^\s*linux" /boot/grub/grub.cfg linux /vmlinuz-4.15.0-55-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash $vt_handoff audit=1 linux /vmlinuz-4.15.0-55-generic root=/dev/mapper/ubuntu--vg-root ro recovery nomodeset audit=1 If any linux lines do not contain "audit=1", this is a finding.

Fix: F-20873r304776_fix

Configure the Ubuntu operating system to produce audit records at system startup. Edit /etc/default/grub file and add "audit=1" to the GRUB_CMDLINE_LINUX option. To update the grub config file run, sudo update-grub

Generate Mitigation Statement:

Checks: C-20875r304778_chk

If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable. Verify the Ubuntu operating system prevents unauthorized disclosure or modification of all information requiring at rest protection by using disk encryption. Determine the partition layout for the system with the following command: #sudo fdisk -l (..) Disk /dev/vda: 15 GiB, 16106127360 bytes, 31457280 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 83298450-B4E3-4B19-A9E4-7DF147A5FEFB Device Start End Sectors Size Type /dev/vda1 2048 4095 2048 1M BIOS boot /dev/vda2 4096 2101247 2097152 1G Linux filesystem /dev/vda3 2101248 31455231 29353984 14G Linux filesystem (...) Verify that the system partitions are all encrypted with the following command: # more /etc/crypttab Every persistent disk partition present must have an entry in the file. If any partitions other than the boot partition or pseudo file systems (such as /proc or /sys) are not listed, this is a finding.

Fix: F-20874r304779_fix

To encrypt an entire partition, dedicate a partition for encryption in the partition layout. Note: Encrypting a partition in an already-installed system is more difficult because the existing partitions must be resized and changed.

Generate Mitigation Statement:

Checks: C-20880r304793_chk

Verify that Advance package Tool (APT) is configured to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Check that the "AllowUnauthenticated" variable is not set at all or set to "false" with the following command: # grep AllowUnauthenticated /etc/apt/apt.conf.d/* /etc/apt/apt.conf.d/01-vendor-Ubuntu:APT::Get::AllowUnauthenticated "false"; If any of the files returned from the command with "AllowUnauthenticated" set to "true", this is a finding.

Fix: F-20879r304794_fix

Configure Advance package Tool (APT) to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Remove/Update any APT configuration file that contain the variable "AllowUnauthenticated" to "false", or remove "AllowUnauthenticated" entirely from each file. Below is an example of setting the "AllowUnauthenticated" variable to "false": APT::Get::AllowUnauthenticated "false";

Generate Mitigation Statement:

Checks: C-20881r304796_chk

Verify Advance package Tool (APT) is configured to remove all software components after updated versions have been installed. Check that APT is configured to remove all software components after updating with the following command: # grep -i remove-unused /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; If the "::Remove-Unused-Dependencies" and "::Remove-Unused-Kernel-Packages" parameters are not set to "true", or are missing, or are commented out, this is a finding.

Fix: F-20880r304797_fix

Configure APT to remove all software components after updated versions have been installed. Add or updated the following options to the "/etc/apt/apt.conf.d/50unattended-upgrades" file: Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

Generate Mitigation Statement:

Checks: C-20884r621647_chk

Check that the "mfetp" package has been installed: # dpkg -l | grep mfetp If the "mfetp" package is not installed, this is a finding. Check that the daemon is running: # /opt/McAfee/ens/tp/init/mfetpd-control.sh status If the daemon is not running, this is a finding.

Fix: F-20883r621648_fix

Configure the Ubuntu operating system to use ENSLTP. Install the mfetp package, # sudo apt-get install mfetp

Generate Mitigation Statement:

Checks: C-20885r304808_chk

Verify the log service is configured to collect system failure events. Check that the log service is installed properly with the following command: # dpkg -l | grep rsyslog ii rsyslog 8.32.0-1ubuntu4 amd64 reliable system and kernel logging daemon If the "rsyslog" package is not installed, this is a finding. Check that the log service is enabled with the following command: # sudo systemctl is-enabled rsyslog enabled If the command above returns "disabled", this is a finding. Check that the log service is properly running and active on the system with the following command: # systemctl is-active rsyslog active If the command above returns "inactive", this is a finding.

Fix: F-20884r304809_fix

Configure the log service to collect failure events. Install the log service (if the log service is not already installed) with the following command: # sudo apt-get install rsyslog Enable the log service with the following command: # sudo systemctl enable rsyslog Restart the log service with the following command: # sudo systemctl restart rsyslog

Generate Mitigation Statement:

Checks: C-20886r304811_chk

Verify that the Uncomplicated Firewall is installed. Check that the Uncomplicated Firewall is installed with the following command: # dpkg -l | grep ufw ii ufw 0.35-0Ubuntu2 If the "ufw" package is not installed, ask the System Administrator is another application firewall is installed. If no application firewall is installed this is a finding.

Fix: F-20885r304812_fix

Install the Uncomplicated Firewall by using the following command: # sudo apt-get install ufw

Generate Mitigation Statement:

Checks: C-20891r802353_chk

Verify that the Ubuntu operating system utilizes the "pam_faillock" module with the following command: $ grep faillock /etc/pam.d/common-auth auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc If the pam_faillock.so module is not present in the "/etc/pam.d/common-auth" file, this is a finding. Verify the pam_faillock module is configured to use the following options: $ sudo egrep 'silent|audit|deny|fail_interval| unlock_time' /etc/security/faillock.conf audit silent deny = 3 fail_interval = 900 unlock_time = 0 If the "silent" keyword is missing or commented out, this is a finding. If the "audit" keyword is missing or commented out, this is a finding. If the "deny" keyword is missing, commented out, or set to a value greater than 3, this is a finding. If the "fail_interval" keyword is missing, commented out, or set to a value greater than 900, this is a finding. If the "unlock_time" keyword is missing, commented out, or is not set to 0, this is a finding.

Fix: F-20890r802354_fix

Configure the Ubuntu operating system to utilize the "pam_faillock" module. Edit the /etc/pam.d/common-auth file. Add the following lines below the "auth" definition for pam_unix.so: auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc Configure the "pam_faillock" module to use the following options: Edit the /etc/security/faillock.conf file and add/update the following keywords and values: audit silent deny = 3 fail_interval = 900 unlock_time = 0

Generate Mitigation Statement:

Checks: C-20892r304829_chk

Verify the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Note: If the system does not have Graphical User Interface installed, this requirement is Not Applicable. Check that the operating system displays the exact approved Standard Mandatory DoD Notice and Consent Banner text with the command: # grep banner-message-enable /etc/gdm3/greeter.dconf-defaults banner-message-enable=true If the line is commented out or set to "false", this is a finding. # grep banner-message-text /etc/gdm3/greeter.dconf-defaults banner-message-text="You are accessing a U.S. Government \(USG\) Information System \(IS\) that is provided for USG-authorized use only.\s+By using this IS \(which includes any device attached to this IS\), you consent to the following conditions:\s+-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct \(PM\), law enforcement \(LE\), and counterintelligence \(CI\) investigations.\s+-At any time, the USG may inspect and seize data stored on this IS.\s+-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\s+-This IS includes security measures \(e.g., authentication and access controls\) to protect USG interests--not for your personal benefit or privacy.\s+-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the banner-message-text is missing, commented out, or the text does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.

Fix: F-20891r304830_fix

Edit the /etc/gdm3/greeter.dconf-defaults file. Uncomment (remove the leading '#' characters) the following 3 configuration lines: [org/gnome/login-screen] banner-message-enable=true banner-message-text='Welcome' Note: the lines are all near the bottom of the file but they are not adjacent to each other. Edit the banner-message-text='Welcome' line to contain the appropriate banner message text as shown below: banner-message-text='You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.' Note that it is similar to the text in /etc/issue but it is all on a single line and the newline characters have been replaced with \n. # sudo dconf update # sudo systemctl restart gdm3

Generate Mitigation Statement:

Checks: C-20893r304832_chk

Verify the Ubuntu operating system prevents direct logins to the root account. Check that the Ubuntu operating system prevents direct logins to the root account with the following command: # sudo passwd -S root root L 11/11/2017 0 99999 7 -1 If the output does not contain "L" in the second field to indicate the account is locked, this is a finding.

Fix: F-20892r304833_fix

Configure the Ubuntu operating system to prevent direct logins to the root account by performing the following operations: sudo passwd -l root

Generate Mitigation Statement:

Checks: C-20895r304838_chk

Verify the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via a ssh logon. Check that the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via a ssh logon with the following command: # grep -i banner /etc/ssh/sshd_config Banner /etc/issue The command will return the banner option along with the name of the file that contains the ssh banner. If the line is commented out, this is a finding. Check the specified banner file to check that it matches the Standard Mandatory DoD Notice and Consent Banner exactly: # cat /etc/issue “You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.” If the banner text does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.

Fix: F-20894r304839_fix

Configure the Ubuntu operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via SSH logon. Edit the SSH daemon configuration "/etc/ssh/sshd_config" file. Uncomment the banner keyword and configure it to point to the file that contains the correct banner. An example of this configure is below: Banner /etc/issue Either create the file containing the banner, or replace the text in the file with the Standard Mandatory DoD Notice and Consent Banner. The DoD required text is: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." In order for the changes to take effect, the SSH daemon must be restarted. # sudo systemctl restart sshd.service

Generate Mitigation Statement:

Checks: C-20901r304856_chk

Verify that the shadow password suite configuration is set to encrypt password with a FIPS 140-2 approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: # cat /etc/login.defs | grep -i crypt ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Fix: F-20900r304857_fix

Configure the Ubuntu operating system to encrypt all stored passwords. Edit/Modify the following line in the "/etc/login.defs" file and set "ENCRYPT_METHOD" to SHA512. ENCRYPT_METHOD SHA512

Generate Mitigation Statement:

Checks: C-20906r304871_chk

Verify if the pwquality configuration file enforces a minimum 15-character password length, by running the following command: # grep -i minlen /etc/security/pwquality.conf minlen=15 If "minlen" parameter value is not 15 or higher, or is commented out, this is a finding.

Fix: F-20905r304872_fix

Configure the Ubuntu operating system to enforce a minimum 15-character password length. Add, or modify the "minlen" parameter value to the "/etc/security/pwquality.conf" file: minlen=15

Generate Mitigation Statement:

Checks: C-20907r304874_chk

Verify that encrypted passwords stored in /etc/shadow use a strong cryptographic hash. Check that pam_unix.so auth is configured to use sha512 with the following command: # grep password /etc/pam.d/common-password | grep pam_unix password [success=1 default=ignore] pam_unix.so obscure sha512 If "sha512" is not an option of the output, or is commented out, this is a finding. Check that ENCRYPT_METHOD is set to sha512 in /etc/login.defs: # grep -i ENCRYPT_METHOD /etc/login.defs ENCRYPT_METHOD SHA512 If the output does not contain "sha512", or it is commented out, this is a finding.

Fix: F-20906r304875_fix

Configure the Ubuntu operating system to encrypt all stored passwords with a strong cryptographic hash. Edit/modify the following line in the file "/etc/pam.d/common-password" file to include the sha512 option for pam_unix.so: password [success=1 default=ignore] pam_unix.so obscure sha512 Edit/modify /etc/login.defs and set "ENCRYPT_METHOD sha512".

Generate Mitigation Statement:

Checks: C-20908r304877_chk

Verify a policy exists that ensures when a user account is created, it is created using a method that forces a user to change their password upon their next login. If a policy does not exist, this is a finding.

Fix: F-20907r304878_fix

Create a policy that ensures when a user is created, it is created using a method that forces a user to change their password upon their next login. Below are two examples of how to create a user account that requires the user to change their password upon their next login. # chage -d 0 [UserName] or # passwd -e [UserName]

Generate Mitigation Statement:

Checks: C-20909r304880_chk

Verify that the Ubuntu operating system uses the cracklib library to prevent the use of dictionary words with the following command: # grep dictcheck /etc/security/pwquality.conf dictcheck=1 If the "dictcheck" parameter is not set to "1", or is commented out, this is a finding.

Fix: F-20908r304881_fix

Configure the Ubuntu operating system to prevent the use of dictionary words for passwords. Add or update the following line in the "/etc/security/pwquality.conf" file to include the "dictcheck=1" parameter: dictcheck=1

Generate Mitigation Statement:

Checks: C-20910r304883_chk

Verify that "/etc/sudoers" has no occurrences of "NOPASSWD" or "!authenticate". Check that the "/etc/sudoers" file has no occurrences of "NOPASSWD" or "!authenticate" by running the following command: # sudo egrep -i '(nopasswd|!authenticate)' /etc/sudoers /etc/sudoers.d/* If any occurrences of "NOPASSWD" or "!authenticate" return from the command, this is a finding.

Fix: F-20909r304884_fix

Remove any occurrence of "NOPASSWD" or "!authenticate" found in "/etc/sudoers" file or files in the /etc/sudoers.d directory.

Generate Mitigation Statement:

Checks: C-20911r569487_chk

Verify the Ubuntu operating system has the libpam-pwquality package installed, by running the following command: # dpkg -l libpam-pwquality ii libpam-pwquality:amd64 1.4.0-2 amd64 PAM module to check password strength If "libpam-pwquality" is not installed, this is a finding. Verify the operating system uses "pwquality" to enforce the password complexity rules. Verify the pwquality module is being enforced by the Ubuntu Operating System, by running the following command: # grep -i enforcing /etc/security/pwquality.conf enforcing = 1 If the value of "enforcing" is not 1 or the line is commented out, this is a finding. Check for the use of "pwquality" with the following command: # sudo cat /etc/pam.d/common-password | grep requisite | grep pam_pwquality password requisite pam_pwquality.so retry=3 enforce_for_root If no output is returned or the line is commented out, this is a finding. If the value of "retry" is set to "0" or greater than "3", this is a finding. If "enforce_for_root" is missing from the configuration line, this is a finding.

Fix: F-20910r569488_fix

Configure the operating system to use "pwquality" to enforce password complexity rules. Install the pam_pwquality package by using the following command: # apt-get install libpam-pwquality -y Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): enforcing = 1 Add the following line to "/etc/pam.d/common-password" (or modify the line to have the required value): password requisite pam_pwquality.so retry=3 enforce_for_root Note: The value of "retry" should be between "1" and "3".

Generate Mitigation Statement:

Checks: C-20912r304889_chk

Verify that all public (world writeable) directories have the public sticky bit set. Find world-writable directories that lack the sticky bit by running the following command: # sudo find / -type d -perm -002 ! -perm -1000 If any world-writable directories are found missing the sticky bit, this is a finding.

Fix: F-20911r304890_fix

Configure all public directories to have the sticky bit set to prevent unauthorized and unintended information transferred via shared system resources. Set the sticky bit on all public directories using the command, replace "[Public Directory]" with any directory path missing the sticky bit: # sudo chmod +t [Public Directory]

Generate Mitigation Statement:

Checks: C-20913r304892_chk

Verify the Ubuntu operating system has all system log files under the /var/log directory with a permission set to 640, by using the following command: # sudo find /var/log -perm /137 -type f -exec stat -c "%n %a" {} \; If command displays any output, this is a finding.

Fix: F-20912r304893_fix

Configured the Ubuntu operating system to set permissions of all log files under /var/log directory to 640 or more restricted, by using the following command: # sudo find /var/log -perm /137 -type f -exec chmod 640 '{}' \;

Generate Mitigation Statement:

Checks: C-20914r304895_chk

Verify the Ubuntu operating system configures the /var/log directory to be group-owned by syslog. Check that the /var/log directory is group owned by syslog with the following command: # sudo stat -c "%n %G" /var/log /var/log syslog If the /var/log directory is not group-owned by syslog, this is a finding.

Fix: F-20913r304896_fix

Configure the Ubuntu operating system to have syslog group-own the /var/log directory by running the following command: # sudo chgrp syslog /var/log

Generate Mitigation Statement:

Checks: C-20915r304898_chk

Verify the Ubuntu operating system configures the /var/log directory to be owned by root. Check that the /var/log directory is owned by root with the following command: # sudo stat -c "%n %U" /var/log /var/log root If the /var/log directory is not owned by root, this is a finding.

Fix: F-20914r304899_fix

Configure the Ubuntu operating system to have root own the /var/log directory by running the following command: # sudo chown root /var/log

Generate Mitigation Statement:

Checks: C-20916r304901_chk

Verify that the Ubuntu operating system configures the /var/log directory with a mode of 750 or less permissive. Check the mode of the /var/log directory with the following command: # stat -c "%n %a" /var/log /var/log 750 If a value of "750" or less permissive is not returned, this is a finding.

Fix: F-20915r304902_fix

Configure the Ubuntu operating system to have permissions of 0750 for the /var/log directory by running the following command: # sudo chmod 0750 /var/log

Generate Mitigation Statement:

Checks: C-20917r304904_chk

Verify that the Ubuntu operating system configures the /var/log/syslog file to be group-owned by adm. Check that the /var/log/syslog file is group-owned by adm with the following command: # sudo stat -c "%n %G" /var/log/syslog /var/log/syslog adm If the /var/log/syslog file is not group-owned by adm, this is a finding.

Fix: F-20916r304905_fix

Configure the Ubuntu operating system to have adm group-own the /var/log/syslog file by running the following command: # sudo chgrp adm /var/log/syslog

Generate Mitigation Statement:

Checks: C-20918r304907_chk

Verify that the Ubuntu operating system configures the /var/log/syslog file to be owned by syslog. Check that the /var/log/syslog file is owned by syslog with the following command: # sudo stat -c "%n %U" /var/log/syslog /var/log/syslog syslog If the /var/log/syslog file is not owned by syslog, this is a finding.

Fix: F-20917r304908_fix

Configure the Ubuntu operating system to have syslog own the /var/log/syslog file by running the following command: # sudo chown syslog /var/log/syslog

Generate Mitigation Statement:

Checks: C-20919r304910_chk

Verify that the Ubuntu operating system configures the /var/log/syslog file with mode 0640 or less permissive. Check the /var/log/syslog permissions by running the following command: # stat -c "%n %a" /var/log/syslog /var/log/syslog 640 If a value of "640" or less permissive is not returned, this is a finding.

Fix: F-20918r304911_fix

Configure the Ubuntu operating system to have permissions of 0640 o for the /var/log/syslog file by running the following command: # sudo chmod 0640 /var/log/syslog

Generate Mitigation Statement:

Checks: C-20920r304913_chk

Verify the audit tools are protected from unauthorized access, deletion, or modification by checking the permissive mode. For each audit tool, /sbin/auditctl, /sbin/aureport, /sbin/ausearch, /sbin/autrace, /sbin/auditd, /sbin/audispd, /sbin/augenrules Check the permissions by running the following command: # stat -c "%n %a" /sbin/auditctl 755 /sbin/auditctl If any of the audit tools have a mode more permissive than 0755, this is a finding.

Fix: F-20919r304914_fix

Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the correct permissive mode using the following command: # sudo chmod 0755 [audit_tool] Replace "[audit_tool]" with the audit tool that does not have the correct permissive mode.

Generate Mitigation Statement:

Checks: C-20921r304916_chk

Verify the Ubuntu operating system configures the audit tools to be owned by root to prevent any unauthorized access, deletion, or modification. For each audit tool, /sbin/auditctl, /sbin/aureport, /sbin/ausearch, /sbin/autrace, /sbin/auditd, /sbin/audispd, /sbin/augenrules Check the ownership by running the following command: # stat -c "%n %U" /sbin/auditctl /sbin/auditctl root If any of the audit tools are not owned by root, this is a finding.

Fix: F-20920r304917_fix

Configure the audit tools on the Ubuntu operating system to be owned by root, by running the following command: # sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by root.

Generate Mitigation Statement:

Checks: C-20922r304919_chk

Verify the Ubuntu operating system configures the audit tools to be group-owned by root to prevent any unauthorized access, deletion, or modification. For each audit tools, /sbin/auditctl, /sbin/aureport, /sbin/ausearch, /sbin/autrace, /sbin/auditd, /sbin/audispd, /sbin/augenrules Check the group-owner of each audit tool by running the following commands: stat -c "%n %G" /sbin/auditctl /sbin/auditctl root If any of the audit tools are not group-owned by root, this is a finding.

Fix: F-20921r304920_fix

Configure the audit tools on the Ubuntu operating system to be group-owned by root, by running the following command: # sudo chgrp root [audit_tool] Replace "[audit_tool]" with each audit tool not group-owned by root.

Generate Mitigation Statement:

Checks: C-20923r802356_chk

Verify the system-wide shared library files contained in the directories "/lib", "/lib64" and "/usr/lib" have mode 0755 or less permissive. Check that the system-wide shared library files have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type f -exec stat -c "%n %a" '{}' \; /usr/lib64/pkcs11-spy.so If any library files are found to be group-writable or world-writable, this is a finding.

Fix: F-20922r802357_fix

Configure the library files to be protected from unauthorized access. Run the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type f -iname *.so* -exec chmod 755 '{}' \

Generate Mitigation Statement:

Checks: C-20924r569465_chk

Verify the system-wide shared library directories "/lib", "/lib64" and "/usr/lib have mode 0755 or less permissive. Check that the system-wide shared library directories have mode 0755 or less permissive with the following command: # sudo find /lib /lib64 /usr/lib -perm /022 -type d -exec stat -c "%n %a" '{}' \; If any of the aforementioned directories are found to be group-writable or world-writable, this is a finding.

Fix: F-20923r569490_fix

Configure the shared library directories to be protected from unauthorized access. Run the following command: # sudo find /lib /lib64 /usr/lib -perm /022 -type d -exec chmod 755 '{}' \;

Generate Mitigation Statement:

Checks: C-20925r304928_chk

Verify the system-wide shared library files contained in the directories "/lib", "/lib64" and "/usr/lib" are owned by root. Check that the system-wide shared library files are owned by root with the following command: # sudo find /lib /usr/lib /lib64 ! -user root -type f -exec stat -c "%n %U" '{}' \; If any system wide library file is returned, this is a finding.

Fix: F-20924r304929_fix

Configure the system library files to be protected from unauthorized access. Run the following command: # sudo find /lib /usr/lib /lib64 ! -user root -type f -exec chown root '{}' \;

Generate Mitigation Statement:

Checks: C-20926r304931_chk

Verify the system-wide shared library directories "/lib", "/lib64" and "/usr/lib" are owned by root. Check that the system-wide shared library directories are owned by root with the following command: # sudo find /lib /usr/lib /lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \; If any system wide library directory is returned, this is a finding.

Fix: F-20925r304932_fix

Configure the library files and their respective parent directories to be protected from unauthorized access. Run the following command: # sudo find /lib /usr/lib /lib64 ! -user root -type d -exec chown root '{}' \;

Generate Mitigation Statement:

Checks: C-20927r802359_chk

Verify the system-wide library files contained in the directories "/lib", "/lib64" and "/usr/lib" are group-owned by root. Check that the system-wide library files are group-owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type f -exec stat -c "%n %G" '{}' \; If any system wide shared library file is returned, this is a finding.

Fix: F-20926r802360_fix

Configure the system library files to be protected from unauthorized access. Run the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type f -iname *.so* -exec chgrp root '{}' \;

Generate Mitigation Statement:

Checks: C-20928r304937_chk

Verify the system-wide library directories "/lib", "/lib64" and "/usr/lib" are group-owned by root. Check that the system-wide library directories are group-owned by root with the following command: # sudo find /lib /usr/lib /lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system wide shared library directory is returned, this is a finding.

Fix: F-20927r304938_fix

Configure the system library directories to be protected from unauthorized access. Run the following command: # sudo find /lib /usr/lib /lib64 ! -group root -type d -exec chgrp root '{}' \;

Generate Mitigation Statement:

Checks: C-20929r304940_chk

Verify the system commands contained in the following directories have mode 0755 or less permissive: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Check that the system command files have mode 0755 or less permissive with the following command: # find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type f -exec stat -c "%n %a" '{}' \; If any files are found to be group-writable or world-writable, this is a finding.

Fix: F-20928r304941_fix

Configure the system commands to be protected from unauthorized access. Run the following command: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type f -exec chmod 755 '{}' \;

Generate Mitigation Statement:

Checks: C-20930r304943_chk

Verify the system commands directories have mode 0755 or less permissive: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Check that the system command directories have mode 0755 or less permissive with the following command: # find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type d -exec stat -c "%n %a" '{}' \; If any directories are found to be group-writable or world-writable, this is a finding.

Fix: F-20929r304944_fix

Configure the system commands directories to be protected from unauthorized access. Run the following command: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type d -exec chmod -R 755 '{}' \;

Generate Mitigation Statement:

Checks: C-20931r304946_chk

Verify the system commands contained in the following directories are owned by root: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Use the following command for the check: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type f -exec stat -c "%n %U" '{}' \; If any system commands are returned, this is a finding.

Fix: F-20930r304947_fix

Configure the system commands - and their respective parent directories - to be protected from unauthorized access. Run the following command: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type f -exec chown root '{}' \;

Generate Mitigation Statement:

Checks: C-20932r304949_chk

Verify the system commands directories are owned by root: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Use the following command for the check: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type d -exec stat -c "%n %U" '{}' \; If any system commands directories are returned, this is a finding.

Fix: F-20931r304950_fix

Configure the system commands directories to be protected from unauthorized access. Run the following command: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type d -exec chown root '{}' \;

Generate Mitigation Statement:

Checks: C-20933r648686_chk

Verify the system commands contained in the following directories are group-owned by root: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Run the check with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type f -exec stat -c "%n %G" '{}' \; If any system commands are returned that are not Set Group ID up on execution (SGID) files and owned by a privileged account, this is a finding.

Fix: F-20932r648687_fix

Configure the system commands to be protected from unauthorized access. Run the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type f ! -perm /2000 -exec chgrp root '{}' \;

Generate Mitigation Statement:

Checks: C-20934r304955_chk

Verify the system commands directories are group-owned by root: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Run the check with the following command: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system commands directories are returned that are not Set Group ID up on execution (SGID) files and owned by a privileged account, this is a finding.

Fix: F-20933r304956_fix

Configure the system commands directories to be protected from unauthorized access. Run the following command: # sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type d -exec chgrp root '{}' \;

Generate Mitigation Statement:

Checks: C-20938r304967_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "tallylog" file occur. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep tallylog -w /var/log/tallylog -p wa -k logins If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20937r304968_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "tallylog" file occur. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/tallylog -p wa -k logins Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20939r304970_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "faillog" file occur. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep faillog -w /var/log/faillog -p wa -k logins If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20938r304971_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "faillog" file occur. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/faillog -p wa -k logins Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20940r304973_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "lastlog" file occur. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep lastlog -w /var/log/lastlog -p wa -k logins If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20939r304974_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "lastlog" file occur. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/lastlog -p wa -k logins Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20941r304976_chk

Verify the Ubuntu operating system audits privileged activities. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep sudo.log -w /var/log/sudo.log -p wa -k priv_actions If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20940r304977_fix

Configure the Ubuntu operating system to audit privileged activities. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/sudo.log -p wa -k actions Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20942r304979_chk

Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via /va/rlog/wtmp. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep '/var/log/wtmp' -w /var/log/wtmp -p wa -k logins If the command does not return a line matching the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20941r304980_fix

Configure the audit system to generate audit events showing start and stop times for user access via the /var/log/wtmp file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/wtmp -p wa -k logins Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20943r802362_chk

Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via /var/run/utmp file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/run/utmp' -w /var/run/utmp -p wa -k logins If the command does not return a line matching the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20942r802363_fix

Configure the audit system to generate audit events showing start and stop times for user access via the /var/run/utmp file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/run/utmp -p wa -k logins Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20944r304985_chk

Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via /var/log/btmp file. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep '/var/log/btmp' -w /var/log/btmp -p wa -k logins If the command does not return a line matching the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20943r304986_fix

Configure the audit system to generate audit events showing start and stop times for user access via the /var/log/btmp file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/btmp -p wa -k logins Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20945r304988_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep passwd -w /etc/passwd -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20944r304989_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/passwd -p wa -k usergroup_modification Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20946r304991_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect /etc/group. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep group -w /etc/group -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20945r304992_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group. Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/group -p wa -k usergroup_modification Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20947r304994_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep gshadow -w /etc/gshadow -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20946r304995_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow. Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/gshadow -p wa -k usergroup_modification Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20948r304997_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep shadow -w /etc/shadow -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20947r304998_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow. Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/shadow -p wa -k usergroup_modification Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20949r305000_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect /etc/security/opasswd. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep opasswd -w /etc/security/opasswd -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20948r305001_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/security/opasswd. Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/security/opasswd -p wa -k usergroup_modification Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20950r305003_chk

Verify the audit service is configured to produce audit records. Check that the audit service is installed properly with the following command: # dpkg -l | grep auditd If the "auditd" package is not installed, this is a finding. Check that the audit service is enabled with the following command: # systemctl is-enabled auditd.service If the command above returns "disabled", this is a finding. Check that the audit service is properly running and active on the system with the following command: # systemctl is-active auditd.service active If the command above returns "inactive", this is a finding.

Fix: F-20949r305004_fix

Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: # sudo apt-get install auditd Enable the audit service with the following command: # sudo systemctl enable auditd.service In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20951r305006_chk

Verify that the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) are notified in the event of an audit processing failure. Check that the Ubuntu operating system notifies the SA and ISSO (at a minimum) win the event of an audit processing failure with the following command: # sudo grep action_mail_acct = root /etc/audit/auditd.conf action_mail_acct = root If the value of the "action_mail_acct" keyword is not set to "root" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, this is a finding.

Fix: F-20950r305007_fix

Configure "auditd" service to notify the System Administrator (SA) and Information System Security Officer (ISSO) in the event of an audit processing failure. Edit the following line in "/etc/audit/auditd.conf" to ensure that administrators are notified via email for those situations: action_mail_acct = root Restart the auditd service so the changes take effect: # sudo systemctl restart auditd.service

Generate Mitigation Statement:

Checks: C-20952r305009_chk

Verify the Ubuntu operating system takes the appropriate action when the audit storage volume is full. Check that the Ubuntu operating system takes the appropriate action when the audit storage volume is full with the following command: # sudo grep disk_full_action /etc/audit/auditd.conf disk_full_action = HALT If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, this is a finding.

Fix: F-20951r305010_fix

Configure the Ubuntu operating system to shut down by default upon audit failure (unless availability is an overriding concern). Add or update the following line (depending on configuration "disk_full_action" can be set to "SYSLOG", "HALT" or "SINGLE") in "/etc/audit/auditd.conf" file: disk_full_action = HALT Restart the auditd service so the changes take effect: # sudo systemctl restart auditd.service

Generate Mitigation Statement:

Checks: C-20953r305012_chk

Verify that the audit log files have a mode of "0600" or less permissive. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, check if the audit log files have a mode of "0600" or less by using the following command: # sudo stat -c "%n %a" /var/log/audit/* /var/log/audit/audit.log 600 If the audit log files have a mode more permissive than "0600", this is a finding.

Fix: F-20952r305013_fix

Configure the audit log files to have a mode of "0600" or less permissive. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log files to have a mode of "0600" or less permissive by using the following command: # sudo chmod 0600 /var/log/audit/*

Generate Mitigation Statement:

Checks: C-20954r305015_chk

Verify that the audit log files are owned by "root" account. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, check if the audit log files are owned by the "root" user by using the following command: # sudo stat -c "%n %U" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by an user other than "root", this is a finding.

Fix: F-20953r305016_fix

Configure the audit log files to be owned by "root" user. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log files to be owned by "root" user by using the following command: # sudo chown root /var/log/audit/*

Generate Mitigation Statement:

Checks: C-20955r305018_chk

Verify that the audit log files are owned by "root" group. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, check if the audit log files are owned by the "root" group by using the following command: # sudo stat -c "%n %G" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by a group other than "root", this is a finding.

Fix: F-20954r305019_fix

Configure the audit log files to be owned by "root" group. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log files to be owned by "root" group by using the following command: # sudo chown :root /var/log/audit/*

Generate Mitigation Statement:

Checks: C-20956r305021_chk

Verify that the audit log directory has a mode of "0750" or less permissive. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, check if the directory has a mode of "0750" or less by using the following command: # sudo stat -c "%n %a" /var/log/audit /var/log/audit 750 If the audit log directory has a mode more permissive than "0750", this is a finding.

Fix: F-20955r305022_fix

Configure the audit log directory to have a mode of "0750" or less permissive. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log directory to have a mode of "0750" or less permissive by using the following command: # chmod -R g-w,o-rwx /var/log/audit

Generate Mitigation Statement:

Checks: C-20957r305024_chk

Verify that the audit log directory is owned by "root" account. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, check if the directory is owned by the "root" user by using the following command: # sudo stat -c "%n %U" /var/log/audit /var/log/audit root If the audit log directory is owned by an user other than "root", this is a finding.

Fix: F-20956r305025_fix

Configure the audit log directory to be owned by "root" user. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log directory to be owned by "root" user by using the following command: # chown -R root /var/log/audit

Generate Mitigation Statement:

Checks: C-20958r305027_chk

Verify that the audit log directory is owned by "root" group. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, check if the directory is owned by the "root" group by using the following command: # sudo stat -c "%n %G" /var/log/audit /var/log/audit root If the audit log directory is owned by a group other than "root", this is a finding.

Fix: F-20957r305028_fix

Configure the audit log directory to be owned by "root" group. First determine where the audit logs are stored with the following command: # sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log directory to be owned by "root" group by using the following command: # chown -R :root /var/log/audit

Generate Mitigation Statement:

Checks: C-20959r305030_chk

Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files have a mode of 0640 or less permissive by using the following command: # sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: drwxr-x--- 3 root root 4096 Nov 25 11:02 . drwxr-xr-x 130 root root 12288 Dec 19 13:42 .. -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: drwxr-x--- 2 root root 4096 Dec 27 09:56 . drwxr-x--- 3 root root 4096 Nov 25 11:02 .. -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If "/etc/audit/audit.rule","/etc/audit/rules.d/*" or "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding.

Fix: F-20958r305031_fix

Configure "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files to have a mode of 0640 by using the following command: # chmod -R 0640 /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/* Note: The "root" account must be used to edit any files in the /etc/audit and /etc/audit/rules.d/ directories.

Generate Mitigation Statement:

Checks: C-20960r305033_chk

Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files are owned by root account by using the following command: # sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: drwxr-x--- 3 root root 4096 Nov 25 11:02 . drwxr-xr-x 130 root root 12288 Dec 19 13:42 .. -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: drwxr-x--- 2 root root 4096 Dec 27 09:56 . drwxr-x--- 3 root root 4096 Nov 25 11:02 .. -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If "/etc/audit/audit.rules" or "/etc/audit/rules.d/*" or "/etc/audit/auditd.conf" file is owned by a user other than "root", this is a finding.

Fix: F-20959r305034_fix

Configure "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files to be owned by root user by using the following command: # chown root /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/* Note: The "root" account must be used to edit any files in the /etc/audit and /etc/audit/rules.d/ directories.

Generate Mitigation Statement:

Checks: C-20961r305036_chk

Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files are owned by root group by using the following command: # sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: drwxr-x--- 3 root root 4096 Nov 25 11:02 . drwxr-xr-x 130 root root 12288 Dec 19 13:42 .. -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: drwxr-x--- 2 root root 4096 Dec 27 09:56 . drwxr-x--- 3 root root 4096 Nov 25 11:02 .. -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If "/etc/audit/audit.rules" or "/etc/audit/rules.d/*" or "/etc/audit/auditd.conf" file is owned by a group other than "root", this is a finding.

Fix: F-20960r305037_fix

Configure "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files to be owned by root group by using the following command: # chown :root /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/* Note: The "root" account must be used to edit any files in the /etc/audit and /etc/audit/rules.d/ directories.

Generate Mitigation Statement:

Checks: C-20963r569456_chk

Verify if the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use the "su" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep '/bin/su' -a always,exit -F path=/bin/su -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-priv_change If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20962r569457_fix

Configure the Ubuntu operating system to generate audit records when successful/unsuccessful attempts to use the "su" command occur. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change In order to reload the rules file, issue the following command: # sudo augenrules --load Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory.

Generate Mitigation Statement:

Checks: C-20964r305045_chk

Verify if the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use of the "chfn" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep '/usr/bin/chfn' -a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-chfn If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20963r305046_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "chfn" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chfn In order to reload the rules file, issue the following command: # sudo augenrules --load Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory.

Generate Mitigation Statement:

Checks: C-20965r305048_chk

Verify if the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use of the "mount" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep '/bin/mount' -a always,exit -F path=/bin/mount -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-mount If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20964r305049_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/bin/mount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-mount In order to reload the rules file, issue the following command: # sudo augenrules --load Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory.

Generate Mitigation Statement:

Checks: C-20966r305051_chk

Verify if the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use of the "umount" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep '/bin/umount' -a always,exit -F path=/bin/umount -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-umount If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20965r305052_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-umount In order to reload the rules file, issue the following command: # sudo augenrules --load Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory.

Generate Mitigation Statement:

Checks: C-20967r305054_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "ssh-agent" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep '/usr/bin/ssh-agent' -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-ssh If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20966r305055_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-agent" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh In order to reload the rules file, issue the following command: # sudo augenrules --load Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory.

Generate Mitigation Statement:

Checks: C-20968r305057_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "ssh-keysign" command occur. Check the configured audit rules with the following commands: #sudo auditctl -l | grep ssh-keysign -a always,exit -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-ssh If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20967r305058_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-keysign" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh In order to reload the rules file, issue the following command: # sudo augenrules --load Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory.

Generate Mitigation Statement:

Checks: C-20969r305060_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "setxattr" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep setxattr -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20968r305061_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setxattr" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20970r305063_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "lsetxattr" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep lsetxattr -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20969r305064_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lsetxattr" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20971r305066_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fsetxattr" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep fsetxattr -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20970r305067_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fsetxattr" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20972r648691_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "removexattr" system call. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep removexattr -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20971r305070_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "removexattr" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20973r305072_chk

Verify if the Ubuntu operating system is configured to audit the execution of the "lremovexattr" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | lremovexattr -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20972r305073_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lremovexattr" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20974r305075_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fremovexattr" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep fremovexattr -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20973r305076_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fremovexattr" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20975r305078_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chown" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep chown -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20974r305079_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20976r569459_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchown" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep fchown -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20975r569460_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchown" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20977r305084_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchownat" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep fchownat -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20976r305085_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchownat" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20978r305087_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "lchown" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep lchown -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20977r305088_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lchown" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20979r305090_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chmod" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep chmod -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20978r305091_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20980r305093_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchmod" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep fchmod -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20979r305094_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20981r305096_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchmodat" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep fchmodat -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20980r305097_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmodat" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20982r305099_chk

Verify the Ubuntu operating system generates an audit record when unsuccessful attempts to use the "open" system call occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep open -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20981r305100_fix

Configure the audit system to generate an audit event for any unsuccessful use of the "open" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20986r305111_chk

Verify the Ubuntu operating system generates an audit record when unsuccessful attempts to use the "openat" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep openat -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20985r305112_fix

Configure the audit system to generate an audit event for any unsuccessful use of the "openat" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20987r305114_chk

Verify the Ubuntu operating system generates an audit record when unsuccessful attempts to use the "open_by_handle_at" system call. Check the configured audit rules with the following command: # sudo auditctl -l | grep open_by_handle_at -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20986r305115_fix

Configure the audit system to generate an audit event for any unsuccessful use of the "open_by_handle_at" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20988r305117_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command. Check the configured audit rules with the following command: # sudo auditctl -l | grep /usr/bin/sudo -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20987r305118_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20989r305120_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "sudoedit" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep /usr/bin/sudoedit -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20988r305121_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudoedit" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20990r305123_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chsh" command. Check the configured audit rules with the following commands: # sudo auditctl -l | grep chsh -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20989r305124_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20991r305126_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "newgrp" command occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep newgrp -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20990r305127_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20992r305129_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chcon" command occur. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep chcon -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20991r305130_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20993r305132_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "apparmor_parser" command occur. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep apparmor_parser -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20992r305133_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "apparmor_parser" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20994r305135_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "setfacl" command occur. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep setfacl -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20993r305136_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfacl" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20995r305138_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chacl" command occur. Check the currently configured audit rules with the following command: # sudo audtctl -l | grep chacl -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above. If the command does not return a line that matches the example or the line is commented out, this is a finding.

Fix: F-20994r305139_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chacl" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20996r305141_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "passwd" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w passwd -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-passwd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20995r755155_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "passwd" command. Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-passwd Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20997r305144_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w unix_update -a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-unix-update If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20996r305145_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_update" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-unix-update Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20998r305147_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w gpasswd -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-gpasswd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20997r305148_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the gpasswd command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-20999r305150_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w chage -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-chage If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20998r305151_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "chage" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21000r305153_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "usermod" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w usermod -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-usermod If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-20999r305154_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-usermod Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21001r305156_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w crontab -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-crontab If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21000r305157_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "crontab" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-crontab Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21002r305159_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w pam_timestamp_check -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-pam_timestamp_check If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21001r305160_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "pam_timestamp_check" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check Note: The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21004r305165_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "finit_module" syscall. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -w finit_module -a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21003r305166_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "finit_module" syscall. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21006r621650_chk

Verify the Ubuntu operating system audits the execution of privilege functions by auditing the "execve" system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep execve -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21005r621651_fix

Configure the Ubuntu operating system to audit the execution of all privileged functions. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21009r305180_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use fsetxattr system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep fsetxattr -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21008r305181_fix

Configure the audit system to generate audit records for successful/unsuccessful attempts to use fsetxattr system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21010r305183_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use removexattr system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep removexattr -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21009r305184_fix

Configure the audit system to generate audit records for successful/unsuccessful attempts to use removexattr system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21011r305186_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use lremovexattr system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep lremovexattr -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21010r305187_fix

Configure the audit system to generate audit records for successful/unsuccessful attempts to use lremovexattr system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21012r305189_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful use of unlink system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep unlink -a always,exit -F arch=b64 -S unlink -F auid>=1000 -F auid!=-1 -k delete -a always,exit -F arch=b32 -S unlink -F auid>=1000 -F auid!=-1 -k delete If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21011r305190_fix

Configure the audit system to generate audit events when successful/unsuccessful use of unlink system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S unlink -Fauid>=1000 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S unlink -F auid>=1000 -F auid!=4294967295 -k delete Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21013r305192_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful use of unlinkat system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep unlinkat -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=-1 -k delete -a always,exit -F arch=b32 -S unlinkat -F auid>=1000 -F auid!=-1 -k delete If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21012r305193_fix

Configure the audit system to generate audit events when successful/unsuccessful use of the unlinkat system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S unlinkat -Fauid>=1000 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S unlinkat -F auid>=1000 -F auid!=4294967295 -k delete Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21014r305195_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful use of rename system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep rename -a always,exit -F arch=b64 -S rename -F auid>=1000 -F auid!=-1 -k delete -a always,exit -F arch=b32 -S rename -F auid>=1000 -F auid!=-1 -k delete If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21013r305196_fix

Configure the audit system to generate audit events when successful/unsuccessful use of the rename system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S rename -Fauid>=1000 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S rename -F auid>=1000 -F auid!=4294967295 -k delete Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21015r305198_chk

Verify the Ubuntu operating system generates audit records when successful/unsuccessful use of renameat system call. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep renameat -a always,exit -F arch=b64 -S renameat -F auid>=1000 -F auid!=-1 -k delete -a always,exit -F arch=b32 -S renameat -F auid>=1000 -F auid!=-1 -k delete If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21014r305199_fix

Configure the audit system to generate audit events when successful/unsuccessful use of the renameat system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S renameat -Fauid>=1000 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S renameat -F auid>=1000 -F auid!=4294967295 -k delete Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21016r569472_chk

Verify the Ubuntu operating system generates an audit record when adding and deleting kernel modules. Check the currently configured audit rules with the following command: # sudo auditctl -l | grep -E 'init_module|finit_module' -a always,exit -F arch=b32 -S init_module -S finit_module -k modules -a always,exit -F arch=b64 -S init_module -S finit_module -k modules If the command does not return lines that matches the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21015r569473_fix

Configure the audit system to generate audit events when adding and deleting kernel modules. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S init_module -S finit_module -k modules -a always,exit -F arch=b64 -S init_module -S finit_module -k modules Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21018r569478_chk

Verify the Ubuntu operating system generates an audit record when unsuccessful attempts to use the "truncate" system call occur. Check the configured audit rules with the following commands: # sudo auditctl -l | grep truncate -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21017r569479_fix

Configure the audit system to generate an audit event for any unsuccessful use of the "truncate" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21019r569481_chk

Verify the Ubuntu operating system generates an audit record when unsuccessful attempts to use the "ftruncate" system call. Check the configured audit rules with the following command: # sudo auditctl -l | grep ftruncate -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21018r569482_fix

Configure the audit system to generate an audit event for any unsuccessful use of the "ftruncate" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21020r569484_chk

Verify the Ubuntu operating system generates an audit record when unsuccessful attempts to use the "creat" system call. Check the configured audit rules with the following commands: # sudo auditctl -l | grep creat -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21019r569485_fix

Configure the audit system to generate an audit event for any unsuccessful use of the "creat" system call. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21021r305216_chk

Verify if the Ubuntu operating system is configured to audit the "init_module" and "finit_module" syscalls, by running the following command: # sudo auditctl -l | grep -E 'init_module|finit_module' -a always,exit -F arch=b64 -S init_module -S finit_module -F key=modules -a always,exit -F arch=b32 -S init_module -S finit_module -F key=modules If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21020r305217_fix

Configure the audit system to generate an audit event for any use of the "init_module" or "finit_module" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S init_module -S finit_module -F key=modules -a always,exit -F arch=b64 -S init_module -S finit_module -F key=modules Notes: For 32-bit architectures, only the 32-bit specific entries are required. The "root" account must be used to view/edit any files in the /etc/audit/rules.d/ directory. In order to reload the rules file, issue the following command: # sudo augenrules --load

Generate Mitigation Statement:

Checks: C-21022r305219_chk

Verify if the Ubuntu operating system is configured to audit the "delete_module" syscall, by running the following command: # sudo auditctl -l | egrep delete_module -a always,exit -F arch=b64 -S delete_module -F key=modules -a always,exit -F arch=b32 -S delete_module -F key=modules If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The '-k' allows for specifying an arbitrary identifier and the string after it does not need to match the example output above.

Fix: F-21021r305220_fix