Working with Keepalived and SELinux: Ensuring HA and Security

Introduction:

In the realm of modern system administration, two paramount concerns often stand at the forefront: ensuring high availability and maintaining robust security. While high availability protocols and applications such as Keepalived have evolved to keep critical services online, SELinux, the Security-Enhanced Linux, has become a cornerstone for safeguarding system integrity. In this blog, we will delve into the synergy between Keepalived and SELinux. In this blog, you’ll ensure your services remain highly available and bolster the security fortifications of your Linux systems. Read on, as we explore the delicate balance between accessibility and defense in the realm of system administration. Apart from setting up this security groundwork, we’ll explore a few common issues faced while using keepalived scripts with SELinux in enforcing mode on Red Hat Enterprise Linux 8. We’ll discuss the error messages encountered and provide step-by-step instructions to resolve these problems.

The Challenge:

Challenges often arise when running Keepalived scripts in conjunction with SELinux in Enforcing Mode, especially in High Availability setups. These challenges primarily revolve around executing custom scripts, as the tight security policies and permission restrictions can hinder their seamless operation.

Error 1:

Keepalived_vrrp[10096]: Unsafe permissions found for script '/usr/libexec/keepalived/is_postgres_primary.sh' - disabling.
Keepalived_vrrp[10096]: Disabling track script postgres_service due to insecure
Keepalived_vrrp[10096]: Registering gratuitous ARP shared channel

Error 2 (By script_user root in keepalived.conf):

Keepalived_vrrp[10127]: Unable to access script /usr/libexec/keepalived/is_postgres_primary.sh INSTANCENAME IP_TO_CHECK

Resolution:

The /usr/libexec/keepalived directory is automatically created and labeled with sufficient SELinux privileges. This directory is reserved for custom scripts created by users.

1. Directory and Script Permissions: Opening Doors for Script

Ensure that the /usr/libexec/keepalived directory and the custom script have the correct SELinux privileges and executable permissions (Should be the owner of the same user(script_user) in global_defs)

# Set executable permissions for the script

sudo chmod o+x /usr/libexec/keepalived/is_postgres_primary.sh

# Verify permissions

ls -l "/usr/libexec/keepalived/is_postgres_primary.sh

2. SELinux Policy and Software Versions: Updating for Success

Make sure you have the required versions of keepalived and SELinux policies installed. As of the date of writing this post:

• keepalived version should be above 1.3 or newer
• Ensure SELinux-policy and selinux-policy-targeted versions are at least 3.13.1-16.el7 or newer.

3. Script Configuration: Setting Things Right

Update the keepalived.conf file to include the correct script and permissions.

# Update keepalived.conf

sudo nano /etc/keepalived/keepalived.conf

Example:

global_defs {
    script_user postgres postgres
}

vrrp_script postgres_service {
    script "/usr/libexec/keepalived/is_postgres_primary.sh"
    interval 2
    rise 2
    fall 2
}

4. Service Status:

Check the status of the keepalived service to ensure it’s running.

systemctl status keepalived.service

Conclusion:

In the quest for a seamlessly functioning Keepalived setup in High Availability scenarios, tackling SELinux in enforcing mode can indeed be a formidable challenge. Our attempts were marred by script execution hurdles attributed to stringent security regulations and permission constraints. It began with cautionary warnings regarding unsafe permissions and access-related complications for our scripts. However, armed with the knowledge of the appropriate measures, we successfully navigated these obstacles.

Our journey commenced with the meticulous validation of SELinux privileges and executable permissions for both the script and its parent directory. This seemingly minor yet critical step was the key that unlocked previously obstructed pathways.

The following RedHat resources were a huge help, check them out:

https://access.redhat.com/solutions/3880561