The ProcessSizeMax option in [Coredump] section of /etc/systemd/coredump.conf specifies the maximum size in bytes of a core which will be processed. Core dumps exceeding this size may be stored, but the backtrace will not be generated.
A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. Enabling core dumps on production systems is not recommended, however there may be overriding operational requirements to enable advanced debuging. Permitting temporary enablement of core dumps during such situations should be reviewed through local needs and policy.
The Storage option in [Coredump] sectionof /etc/systemd/coredump.conf can be set to none to disable storing core dumps permanently.
A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. Enabling core dumps on production systems is not recommended, however there may be overriding operational requirements to enable advanced debuging. Permitting temporary enablement of core dumps during such situations should be reviewed through local needs and policy.
Verify the /run/log/journal and /var/log/journal directories have permissions set to "2750" or less permissive by using the following command:
$ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %a" {} \;
If any output returned has a permission set greater than "2750", this is a finding.
Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization.
Verify the /run/log/journal and /var/log/journal directories are owned by "root" by using the following command:
$ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %U" {} \;
If any output returned is not owned by "root", this is a finding.
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
Verify the /run/log/journal and /var/log/journal directories are group-owned by "systemd-journal" by using the following command:
$ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %G" {} \;
If any output returned is not owned by "systemd-journal", this is a finding.
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.
To configure the system to ignore the CtrlAltDelBurstAction
setting, add or modify the following to /etc/systemd/system.conf:
CtrlAltDelBurstAction=none
A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot.
To properly set the group owner of /etc/crypttab, run the command:
$ sudo chgrp root /etc/crypttab
The ownership of the /etc/crypttab file by the root group is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
Verify that the "journalctl" command is group-owned by "root" by using the following command:
$ sudo find /usr/bin/journalctl -exec stat -c "%n %G" {} \;
If any output returned is not owned by "root", this is a finding.
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
'
To properly set the group owner of /var/log/journal/.*/system.journal, run the command:
$ sudo chgrp systemd-journal /var/log/journal/.*/system.journal'
RHCOS must protect system journal file from any type of unauthorized access by setting file group ownership.
To properly set the owner of /etc/crypttab, run the command:
$ sudo chown root /etc/crypttab
The ownership of the /etc/crypttab file by the root user is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
Verify that the "journalctl" command is owned by "root" by using the following command:
$ sudo find /usr/bin/journalctl -exec stat -c "%n %U" {} \;
If any output returned is not owned by "root", this is a finding.
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
'
To properly set the owner of /var/log/journal/.*/system.journal, run the command:
$ sudo chown root /var/log/journal/.*/system.journal'
RHCOS must protect system journal file from any type of unauthorized access by setting file ownership
To properly set the permissions of /etc/crypttab, run the command:
$ sudo chmod 0600 /etc/crypttab
Setting correct permissions on the /etc/crypttab file is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
Verify that the "journalctl" command has a permission set of "740" by using the following command:
$ sudo find /usr/bin/journalctl -exec stat -c "%n %a" {} \;
If "journalctl" is not set to "740", this is a finding.
Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization.
To properly set the permissions of /var/log/journal/.*/system.journal, run the command:
$ sudo chmod 0640 /var/log/journal/.*/system.journal
RHCOS must protect system journal file from any type of unauthorized access by setting file permissions.
The journald system can compress large log files to avoid fill the system disk.
Log files that are not properly compressed run the risk of growing so large that they fill up the log partition. Valuable logging information could be lost if the log partition becomes full.
Data from journald may be stored in volatile memory or persisted locally. Utilities exist to accept remote export of journald logs.
Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system.
The journald system may store log files in volatile memory or locally on disk. If the logs are only stored in volatile memory they will we lost upon reboot.
Log files contain valuable data and need to be persistent to aid in possible investigations.
Journald (via systemd-journal-remote ) supports the ability to send log events it gathers to a remote log host or to receive messages from remote hosts, thus enabling centralised log management.
Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system.
The systemd_timesyncd service should be installed.
Time synchronization (using NTP) is required by almost all network and administrative tasks (syslog, cryptographic based services (authentication, etc.), etc.). systemd_timesyncd is a part of the systemd suite and acts as a NTP client.
The systemd_timesyncd service should not be installed.
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate.
SystemD's debug-shell service is intended to
diagnose SystemD related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9. The debug-shell service should only be used
for SystemD related issues and should otherwise be disabled.
By default, the debug-shell SystemD service is already disabled.
The debug-shell service can be disabled with the following command:
$ sudo systemctl mask --now debug-shell.service
This prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted.
The systemd-coredump.socket unit is a socket activation of the systemd-coredump@.service which processes core dumps. By masking the unit, core dump processing is disabled.
A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.
The systemd-journald service is an essential component of
systemd.
The systemd-journald service can be enabled with the following command:
$ sudo systemctl enable systemd-journald.service
In the event of a system failure, Red Hat Enterprise Linux 9 must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to system processes.
Red Hat Enterprise Linux 9 must offload rsyslog messages for networked systems in real time and
offload standalone systems at least weekly.
The systemd-journal-upload service can be enabled with the following command:
$ sudo systemctl enable systemd-journal-upload.service
Red Hat Enterprise Linux 9 must offload rsyslog messages for networked systems in real time and offload standalone systems at least weekly.
systemd-timesyncd is a daemon that has been added for synchronizing the system clock across the network. The systemd-timesyncd daemon implements: - Implements an SNTP client - Runs with minimal privileges - Saves the current clock to disk every time a new NTP sync has been acquired - Is hooked up with networkd to only operate when network connectivity is available Add or edit server or pool lines to /etc/systemd/timesyncd.conf as appropriate:
server <remote-server>Multiple servers may be configured.
Configuring systemd-timesyncd ensures time synchronization is working properly.
systemd-timesyncd server configuration should have RootDistanceMaxSec is listed in accordance with local policy. This setting describes the maximum estimated time required for a packet to travel to the server connected.
Configuring systemd-timesyncd RootDistanceMaxSec ensures time synchronization is using servers that are close enough to the client.
The systemd_timesyncd service can be enabled with the following command:
$ sudo systemctl enable systemd_timesyncd.service
Enabling the systemd_timesyncd service ensures that this host
uses the ntp protocol to fetch time data from a ntp server.
Synchronizing time is essential for authentication
services such as Kerberos, but it is also important for maintaining accurate
logs and auditing possible security breaches.
Additional information on Ubuntu network time protocol is
available at
https://help.ubuntu.com/lts/serverguide/NTP.html.en.
Journald supports the ability to receive messages from remote hosts, thus acting as a log server. Clients should not receive data from other hosts. NOTE: The same package, systemd-journal-remote , is used for both sending logs to remote hosts and receiving incoming logs. With regards to receiving logs, there are two Systemd unit files; systemd-journal-remote.socket and systemd-journal-remote.service.
If a client is configured to also receive data, thus turning it into a server, the client system is acting outside it's operational boundary.
The /tmp directory is a world-writable directory used for temporary file storage. This directory is managed by systemd-tmpfiles. Ensure that the tmp.mount systemd unit is enabled.
The /tmp directory is used as temporary storage by many programs. Placing /tmp in a tmpfs filesystem enables the setting of more restrictive mount options, which can help protect programs which use it. The tmp.mount unit configures the tmpfs filesystem and ensures the /tmp directory is wiped during reboot.
Red Hat Enterprise Linux 9 must offload rsyslog messages for networked systems in real time and offload standalone systems at least weekly
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity
Red Hat Enterprise Linux 9 must offload rsyslog messages for networked systems in real time and offload standalone systems at least weekly
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity