[MXS-2118] Maxscale should have its own SELinux security context, and Keepalived directions should explain how to make them work together when SELinux is enforcing. Created: 2018-10-26  Updated: 2020-01-30  Resolved: 2020-01-30

Status: Closed
Project: MariaDB MaxScale
Component/s: Core, Documentation, Router
Affects Version/s: None
Fix Version/s: N/A

Type: New Feature Priority: Minor
Reporter: Juan Assignee: Niclas Antti
Resolution: Won't Do Votes: 0
Labels: None

Epic Link: Security Improvements
Sprint: MXS-SPRINT-98

 Description   

Although MaxScale runs as an unconfined service under SELinux, keepalived uses the keepalived_t security context, so it does not have rights into /home directories. Therefore it fails when SELinux is enforcing because it cannot see the script under /home/scripts.

Further, the is_maxscale_running.sh procedure ( as written in the walktrhough at at https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-failover-with-keepalived/ ) attempts to write a file, causing a second SELinux error for the same reason, regardless of where the file is written.

Once these two obstacles are overcome by putting is_maxscale_running.sh in /usr/local/sbin/ and re-writing it to capture the output of 'maxadmin list servers' in a variable instead of a file, we run into a third problem: sockets.

MaxScale does not have its own policy, and it would make sense to run MaxScale and Keepalived in the same security context, so an interim solution (alternative to adding just the necessary permissions and nothing else to the keepalived_exec_t security context) is to change the context of keepalived once installed to match that of maxscale.

This can be accomplished in two ways:

in /usr/sbin, you can enter:

chcon system_u:object_r:bin_t:s0 keepalived

(chcon is part of the coreutils package)

alternatively, you can simply rename the executable to /usr/bin/keepalived_old, and then copy it as root with:

cp keepalived_old keepalived

and the new copy will inherit the correct security context.



 Comments   
Comment by markus makela [ 2018-10-28 ]

Would the limitation of the sockets apply to TCP sockets as well? If not, maxctrl could be used to check via the REST API whether MaxScale is running.

Comment by Todd Stoffel (Inactive) [ 2019-05-01 ]

Maybe a better solution would be to remove the need for a third party utility like keepalived in the first place. See MXS-2462

Comment by Juan [ 2019-05-02 ]

Although MaxScale emulating Keepalived functionality, would be a nice addition, that does not address the SELinux issue that MaxScale currently requires an unconfined installation, and that it could look to Keepalived to model how security context implementations usually work, without requiring installation as unconfined.

Comment by Niclas Antti [ 2020-01-30 ]

There are workarounds available to handle this issue in the short term.
The Jira issues below replace this issue:

https://jira.mariadb.org/browse/MXS-2862 - MaxScale SELinux policy
https://jira.mariadb.org/browse/MXS-2462 - Native keepalive function between MaxScale pairs

Generated at Thu Feb 08 04:11:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.