In an era where cybersecurity threats are rampant, maintaining a secure IT infrastructure is more crucial than ever. For organizations using Red Hat Enterprise Linux (RHEL), adhering to the Mandatory Access & Authorization Baseline Security (MBSS) standards is essential to protect sensitive data and ensure compliance with regulatory requirements. This article outlines the key controls and practices necessary for securing RHEL systems, based on guidelines provided by trusted authorities such as the National Institute of Standards and Technology (NIST) and Red Hat’s security documentation.

What are MBSS and RHEL Baseline Security Controls?

Minimum Baseline Security Standards (MBSS)

MBSS are a set of security guidelines aimed at establishing a minimum level of security configurations across an organization’s IT infrastructure. These standards are designed to protect sensitive information and ensure that systems meet legal and regulatory requirements. MBSS typically include various security controls, such as access controls, authorization mechanisms, and configuration best practices.

RHEL Baseline Security Controls

For RHEL systems, baseline security controls encompass a range of settings and configurations aimed at enhancing system security. These controls are based on profiles established by NIST, including the NIST National Checklist for RHEL, as well as guidelines from the U.S. Department of Defense and the National Security Agency. The aim is to provide a robust security posture that protects against both internal and external threats.

Why Implement These Controls?

1. Regulatory Compliance: Adhering to MBSS helps organizations comply with various regulations, including HIPAA, NIST 800-171, and DISA Operating System Security Requirements Guide (OS SRG). Compliance not only avoids legal penalties but also builds trust with stakeholders.
2. Enhanced Security: Implementing these controls mitigates risks by protecting against unauthorized access, data breaches, and other security incidents. It ensures that only authorized users have access to sensitive information and system resources.
3. Operational Efficiency: Standardized security controls streamline security management, making it easier to maintain and monitor compliance across multiple systems. This reduces the complexity and cost associated with managing IT security.

Applicability to Other RHEL-Based Distributions

The Mandatory Access & Authorization Baseline Security controls outlined for RHEL are not only crucial for securing Red Hat Enterprise Linux systems but are equally applicable to other Linux distributions derived from RHEL. This includes CentOS, Rocky Linux, AlmaLinux, Oracle Linux, Scientific Linux, and ClearOS. These distributions share the same core architecture and system components, making the security controls relevant across these platforms.

CentOS

CentOS is a free, community-supported distribution that provides a binary-compatible version of RHEL. Since CentOS is built from the same source code as RHEL, the security controls and best practices for RHEL apply directly to CentOS systems. Implementing these controls in CentOS ensures the same level of security and compliance as in RHEL.

Rocky Linux and AlmaLinux

Rocky Linux and AlmaLinux were developed to fill the gap left by the transition of CentOS to CentOS Stream. Both are designed to be 100% bug-for-bug compatible with RHEL, providing a stable and secure enterprise operating system. The baseline security standards recommended for RHEL are fully applicable to Rocky Linux and AlmaLinux, ensuring these systems can be secured to the same high standards.

Oracle Linux

Oracle Linux is another RHEL-compatible distribution that offers additional features and support for Oracle software. The security controls for RHEL are relevant to Oracle Linux as well, given its close alignment with RHEL. Organizations using Oracle Linux can implement these controls to enhance their security posture.

Scientific Linux

Scientific Linux, created by Fermilab and CERN, is tailored for scientific computing and is also based on RHEL. The baseline security controls for RHEL are crucial for securing Scientific Linux systems, protecting sensitive research data and ensuring compliance with institutional security policies.

ClearOS

ClearOS, aimed at small businesses and home users, is built on the RHEL foundation. The mandatory access and authorization controls applicable to RHEL ensure that ClearOS systems are secure and reliable, providing a robust platform for its users.

Key Controls and Their Importance

1. Ownership and Permissions on Bootloader Config: Ensuring that only the root user has read-write permissions on the bootloader configuration file prevents unauthorized changes that could compromise system boot settings and security parameters.
2. Restrict Access to Core Dumps: Core dumps can contain sensitive information. Restricting access ensures that only authorized personnel can view or modify these files, reducing the risk of data leakage.
3. Configure Permissions on Critical Files: Files like /etc/motd, /etc/issue, and /etc/issue.net should have appropriate permissions to prevent unauthorized modifications. These files often display important messages to users, and tampering could mislead or deceive.
4. Disable Unused Services (e.g., LDAP): Disabling unnecessary services reduces the attack surface. For instance, if the Lightweight Directory Access Protocol (LDAP) is not in use, it should be disabled to prevent potential exploitation.
5. Set Appropriate File Permissions: Critical system files and directories, such as those in /etc/cron.*, /etc/ssh, and /var/log, should have restricted permissions to prevent unauthorized access and modifications.
6. Enforce User Authentication and Authorization Policies: Policies such as restricting root login to system consoles and ensuring that only authorized users can access su and sudo commands are vital for maintaining control over privileged operations.
7. Implement Timeouts and Environment Restrictions: Setting default shell timeouts and disabling SSH PermitUserEnvironment prevent unauthorized users from exploiting idle sessions or setting insecure environment variables.

Details List of all Mandatory Access & Authorization Baseline Security for Red Hat Enterprise Linux (RHEL)

• Ensure ownership and read-write permission on bootloader config are configured to root user only: The grub configuration file contains information on boot settings and passwords for unlocking boot options. Set the owner and group of bootloader configuration to the root user. Setting the owner and group to root prevents non-root users from changing the file. Set permission on the bootloader configuration file to read and write for root only. Setting the permissions to read and write for root only prevents non-root users from seeing the boot parameters or changing them. Non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them.
• Access to Core Dumps should be restricted: A core dump is the memory of an executable program. It is generally used to determine why a program aborted. It can also be used to glean confidential information from a core file. The system provides the ability to set a soft limit for core dumps, but this can be overridden by the user.
• Ensure permissions on /etc/motd are configured: The contents of the /etc/motd file are displayed to users after login and function as a message of the day for authenticated users. If the /etc/motd file does not have the correct ownership it could be modified by unauthorized users with incorrect or misleading information.
• Ensure permissions on /etc/motd are configured: The contents of the /etc/issue file are displayed to users prior to login for local terminals. If the /etc/issue file does not have the correct ownership it could be modified by unauthorized users with incorrect or misleading information.”
• Ensure permissions on /etc/issue.net are configured: The contents of the /etc/issue.net file are displayed to users prior to login for remote connections from configured services. If the /etc/issue.net file does not have the correct ownership it could be modified by unauthorized users with incorrect or misleading information.
• LDAP server should be disabled if not in use: The Lightweight Directory Access Protocol (LDAP) was introduced as a replacement for NIS/YP. It is a service that provides a method for looking up information from a central database.
• Ensure permissions on /etc/hosts.allow and /etc/hosts.deny are configured to be 644: The /etc/hosts.allow and /etc/hosts.deny file contains networking information that is used by many applications and therefore must be readable for these applications to operate. It is critical to ensure that the /etc/hosts.allow and /etc/hosts.deny file is protected from unauthorized write access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions.
• rsyslog/syslog-ng default file permissions should be configured: rsyslog/syslog-ng will create logfiles that do not already exist on the system. This setting controls what permissions will be applied to these newly created files. This setting controls what permissions will be applied to these newly created files. It is important to ensure that log files exist and have the correct permissions to ensure that sensitive syslog-ng data is archived and protected.
• Permissions on all logfiles are configured should be to read-only for group and no read and write access for other: Log files stored in /var/log/ contain logged information from many services on the system, or on log hosts others as well. It is important to ensure that log files have the correct permissions to ensure that sensitive data is archived and protected.
• /etc/crontab should be configured to be owned by root and permission should be configured to deny read and write access to group and other: The /etc/crontab file is used by anacron to control its own jobs. Root permissions should be to the user and group owner of the file.
• /etc/cron.hourly should be configured to be owned by root and permission should be configured to deny read and write access to group and other: The /etc/cron.hourly file is used by anacron to control its own jobs. Root permissions should be to the user and group owner of the file.
• /etc/cron.daily should be configured to be owned by root and permission should be configured to deny read and write access to group and other: The /etc/cron.daily file is used by anacron to control its own jobs. Root permissions should be to the user and group owner of the file.
• /etc/cron.weekly should be configured to be owned by root and permission should be configured to deny read and write access to group and other: The /etc/cron.weekly file is used by anacron to control its own jobs. Root permissions should be to the user and group owner of the file.
• /etc/cron.monthly should be configured to be owned by root and permission should be configured to deny read and write access to group and other: The /etc/cron.weekly file is used by anacron to control its own jobs. Root permissions should be to the user and group owner of the file.
• /etc/cron.d should be configured to be owned by root and permission should be configured to deny read and write access to group and other: The /etc/cron.d file is used by anacron to control its own jobs. Root permissions should be to the user and group owner of the file.
• Ensure at/cron is restricted to authorized users: Configure /etc/cron.allow and /etc/at.allow to allow specific users to use these services. If /etc/cron.allow or /etc/at.allow do not exist, then /etc/at.deny and /etc/cron.deny are checked. Any user not specifically defined in those files is allowed to use at and cron. By removing the files, only users in /etc/cron.allow and/etc/at.allow are allowed to use at and cron. Note that even though a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file only controls administrative access to the crontab command for scheduling and modifying cron jobs.
• /etc/ssh/sshd_config are configured to be owned by root and permission is configured to deny read and write access to group and other: The /etc/ssh/sshd_config file contains configuration specifications for sshd. The command below sets the owner and group of the file to root. The /etc/ssh/sshd_config file needs to be protected from unauthorized changes by non-privileged users.
• Ensure SSH PermitUserEnvironment is disabled: The PermitUserEnvironment option allows users to present environment options to the ssh daemon. Permitting users the ability to set environment variables through the SSH daemon could potentially allow users to bypass security controls (e.g. setting an execution path that has ssh executing trojan’d programs).
• Ensure default group for the root account is GID 0: The usermod command can be used to specify which group the root user belongs to. This affects permissions of files that are created by the root user. Using GID 0 for the root account helps prevent root-owned files from accidentally becoming accessible to non-privileged users.
• Ensure default user shell timeout is 900 seconds or less: The default TMOUT determines the shell timeout for users. The TMOUT value is measured in seconds. Having no timeout value associated with a shell could allow an unauthorized user access to another user’s shell session (e.g. user walks away from their computer and doesn’t lock the screen). Setting a timeout value at least reduces the risk of this happening.
• Ensure root login is restricted to system console: The file /etc/securetty contains a list of valid terminals that may be logged in directly as root.
• Ensure access to the su command is restricted: The su command allows a user to run a command or shell as another user. The program has been superseded by sudo, which allows for more granular control over privileged access. Normally, the su command can be executed by any user. By uncommenting the pam_wheel.so statement in /etc/pam.d/su, the su command will only allow users in the wheel group to execute su.
• Ensure permissions on /etc/passwd and /etc/passwd- are configured: The /etc/passwd file contains user account information that is used by many system utilities and therefore must be readable for these utilities to operate. The /etc/passwd- file contains backup user account information.
• Ensure permissions on /etc/shadow are configured and /etc/shadow- are configured: The /etc/shadow file is used to store the information about user accounts that is critical to the security of those accounts, such as the hashed password and other security information. The /etc/shadow- file is used to store backup information about user accounts that is critical to the security of those accounts, such as the hashed password and other security information.
• Ensure permissions on /etc/group and /etc/group- are configured: The /etc/group file contains a list of all the valid groups defined in the system. The command below allows read/write access for root and read access for everyone else. The /etc/group- file contains a backup list of all the valid groups defined in the system.
• Ensure permissions on /etc/gshadow and /etc/gshadow- are configured: The /etc/gshadow file is used to store the information about groups that is critical to the security of those accounts, such as the hashed password and other security information. The /etc/gshadow- file is used to store backup information about groups that is critical to the security of those accounts, such as the hashed password and other security information.
• Ensure no unowned and ungrouped files or directories exist: Sometimes when administrators delete users from the password file they neglect to remove all files owned by those users from the system. A new user who is assigned the deleted user’s user ID or group ID may then end up ‘owning’ these files, and thus have more access on the system than was intended.
• Ensure that no rogue SUID and SGID programs have been introduced into the system: The owner of a file can set the file’s permissions to run with the owner’s or group’s permissions, even if the user running the program is not the owner or a member of the group. The most common reason for a SUID and SGID program is to enable users to perform functions (such as changing their password) that require root privileges.
• Ensure root is the only UID 0 account: Any account with UID 0 has superuser privileges on the system. This access must be limited to only the default root account and only from the system console. Administrative access must be through an unprivileged account using an approved mechanism.
• Ensure users’ home directories permissions are 750 or more restrictive: While the system administrator can establish secure permissions for users’ home directories, the users can easily override these. Group or world-writable user home directories may enable malicious users to steal or modify other users’ data or to gain another user’s system privileges.
• Ensure users’ dot files are not group or world writable: While the system administrator can establish secure permissions for users’ ‘dot’ files, the users can easily override these.
• Ensure users’ .netrc Files are not group or world accessible: While the system administrator can establish secure permissions for users’ .netrc files, the users can easily override these.
• Ensure no users have .rhosts files: While no .rhosts files are shipped by default, users can easily create them. This action is only meaningful if .rhosts support is permitted in the file /etc/pam.conf. Even though the .rhosts files are ineffective if support is disabled in /etc/pam.conf, they may have been brought over from other systems and could contain information useful to an attacker for those other systems.
• Ensure all groups in /etc/passwd exist in /etc/group: Over time, system administration errors and changes can lead to groups being defined in /etc/passwd but not in /etc/group. Groups defined in the /etc/passwd file but not in the /etc/group file pose a threat to system security since group permissions are not properly managed.

Conclusion

Adhering to the Mandatory Access & Authorization Baseline Security controls is essential not only for RHEL but also for any RHEL-based distribution. These controls help maintain the integrity, confidentiality, and availability of systems across these platforms, providing a uniform security posture that protects against a wide range of threats. By implementing these controls, organizations can ensure that their Linux environments, whether RHEL, CentOS, Rocky Linux, AlmaLinux, Oracle Linux, Scientific Linux, or ClearOS, meet the highest security standards and regulatory requirements.

Implementing and maintaining the Mandatory Access & Authorization Baseline Security controls for RHEL is not just a best practice but a necessity in today’s threat landscape. By following these guidelines, organizations can enhance their security posture, ensure regulatory compliance, and protect their critical assets. The guidelines provided by NIST and Red Hat serve as a comprehensive foundation for achieving a secure and compliant RHEL environment. Investing the time and resources to adhere to these standards will pay off in the form of reduced risk and increased trust from customers and stakeholders.

References:

• IT SECURITY C&T – Minimum Baseline Security Standard Development
• NIST National Checklist for Red Hat Enterprise Linux
• Red Hat Product Documentation – Security Hardening
• Enable Sysadmin – 5 Security Technologies in Red Hat Enterprise Linux

roosho Senior Engineer (Technical Services)

I am Rakib Raihan RooSho, Jack of all IT Trades. You got it right. Good for nothing. I try a lot of things and fail more than that. That's how I learn. Whenever I succeed, I note that in my cookbook. Eventually, that became my blog. 

See Full Bio

IT Support Specialist Server and Storage Specialist Dell MidRange Storage Solutions Specialist