selinux haproxy.cfg Type Label

[Slair1]

We try to keep selinux enabled on our haproxy servers, but with the Data Plane API, the haproxy.cfg file is getting change to a selinux Type of "tmp_t" as shown below. I've even changed the transaction_dir to be /etc/haproxy/tmp so files created there have the correct Type label, but the haproxy.cfg file is still has the tmp_t label type. Since the type label is wrong, selinux denies haproxy access to the haproxy.cfg file.

Before committing the transaction [root@haproxy01 ~]# ls /etc/haproxy/tmp/ -lZ total 8 -rw-r--r--. 1 root root system_u:object_r:tmp_t:s0 4142 Aug 7 03:41 haproxy.cfg.8ec7cbce-1a3c-49f6-949a-4d77a0e43acf

After committing the transaction [root@haproxy01 ~]# ls /etc/haproxy -lZ total 12 drwxr-xr-x. 2 root root system_u:object_r:etc_t:s0 6 Mar 6 07:39 conf.d -rw-r--r--. 1 root root system_u:object_r:etc_t:s0 529 Aug 7 02:54 dataplaneapi.yml drwxr-x---. 2 root root system_u:object_r:etc_t:s0 6 Aug 7 02:54 general -rw-r--r--. 1 root root system_u:object_r:tmp_t:s0 3518 Aug 7 03:29 haproxy.cfg -rw-r--r--. 1 root root system_u:object_r:etc_t:s0 3518 Aug 7 02:54 haproxy.cfg.lkg

audit.log entry: type=AVC msg=audit(1722999318.918:7138): avc: denied { open } for pid=68825 comm="haproxy" path="/etc/haproxy/haproxy.cfg" dev="dm-0" ino=33567110 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0

[dkorunic]

@Slair1 This is happening most likely due to SELinux transition rules that you have and because of how atomic copyFile works with writing to the temp file (with .bck suffix) and renaming the temp file to the actual target name. We would recommend investigating those transition rules and/or overriding them for TransactionDir and /etc/haproxy and keeping all files/folders to etc_t type:

semanage fcontext -a -t etc_t "/etc/haproxy(/.*)?"
restorecon -Rv /etc/haproxy

Also you can always whitelist the access to /etc/haproxy/haproxy.cfg, for instance by using audit2allow.

[Slair1]

@Slair1 This is happening most likely due to SELinux transition rules that you have and because of how atomic copyFile works with writing to the temp file (with .bck suffix) and renaming the temp file to the actual target name. We would recommend investigating those transition rules and/or overriding them for TransactionDir and /etc/haproxy and keeping all files/folders to etc_t type:

semanage fcontext -a -t etc_t "/etc/haproxy(/.*)?"
restorecon -Rv /etc/haproxy

Also you can always whitelist the access to /etc/haproxy/haproxy.cfg, for instance by using audit2allow.

thanks for the reply @dkorunic . We already have the correct rules in-place as shown below:

Can see that haproxy.cfg has type of tmp_t

[root@haproxy01 ~]# ls -lZ /etc/haproxy
total 12
drwxr-xr-x. 2 root root system_u:object_r:etc_t:s0    6 Mar  6 07:39 conf.d
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0  529 Aug  7 02:54 dataplaneapi.yml
drwxr-x---. 2 root root system_u:object_r:etc_t:s0    6 Aug  7 02:54 general
-rw-r--r--. 1 root root system_u:object_r:tmp_t:s0 3518 Aug  7 03:41 haproxy.cfg
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 3518 Aug  7 02:54 haproxy.cfg.lkg
drwxr-x---. 2 root root system_u:object_r:etc_t:s0    6 Aug  7 02:54 maps
drwxr-x---. 2 root root system_u:object_r:etc_t:s0    6 Aug  7 02:54 spoe
drwxr-x---. 2 root root system_u:object_r:etc_t:s0    6 Aug  7 02:54 ssl
drwxr-xr-x. 2 root root system_u:object_r:etc_t:s0   62 Aug  7 03:41 tmp

Use matchpathcon to see if the files match the configured rules This confirms the rules are setup correctly, but the files created by Data Plane API have tmp_t. The trx files are also being created with the wrong type - doesn't match the rules in-place

[root@haproxy01 ~]# matchpathcon -V /etc/haproxy/*
/etc/haproxy/conf.d verified.
/etc/haproxy/dataplaneapi.yml verified.
/etc/haproxy/general verified.
/etc/haproxy/haproxy.cfg has context system_u:object_r:tmp_t:s0, should be system_u:object_r:etc_t:s0
/etc/haproxy/haproxy.cfg.lkg verified.
/etc/haproxy/maps verified.
/etc/haproxy/spoe verified.
/etc/haproxy/ssl verified.
/etc/haproxy/tmp verified.

[root@haproxy01 ~]# matchpathcon -V /etc/haproxy/tmp/*
/etc/haproxy/tmp/haproxy.cfg.171962bc-75de-4d65-9e90-eeb782300759 has context system_u:object_r:tmp_t:s0, should be system_u:object_r:etc_t:s0
/etc/haproxy/tmp/haproxy.cfg.8ec7cbce-1a3c-49f6-949a-4d77a0e43acf has context system_u:object_r:tmp_t:s0, should be system_u:object_r:etc_t:s0

So the rules are correct and if i manually create a file in those directories they have the correct type. It is just files created by the Data Plane API that have the tmp_t type.

[root@haproxy01 ~]# echo test> /etc/haproxy/tmp/mytestfile.cfg.171962bc-75de-4d65-9e90-eeb782300759
[root@haproxy01 ~]# ls -lZ /etc/haproxy/tmp
total 16
-rw-r--r--. 1 root root system_u:object_r:tmp_t:s0     4022 Aug  7 19:13 haproxy.cfg.171962bc-75de-4d65-9e90-eeb782300759
-rw-r--r--. 1 root root system_u:object_r:tmp_t:s0     4142 Aug  7 03:41 haproxy.cfg.8ec7cbce-1a3c-49f6-949a-4d77a0e43acf
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0    5 Aug  7 19:19 mytestfile.cfg.171962bc-75de-4d65-9e90-eeb782300759

Is the Data Plane API creating the trx files in a different directory first then moving them to the TransactionDir maybe?

[Slair1]

Some additional detail using inotifywatch. Data Plan API is actually creating files in /tmp then moving them to the TransactionDir. So no matter what we set on /tmp/haproxy with semanage it is negated since Data Plane API first creates in /tmp them moves.

This is what happens when creating a transaction:

/tmp/ OPEN,ISDIR haproxy
/tmp/haproxy/ OPEN,ISDIR
/tmp/ ACCESS,ISDIR haproxy
/tmp/haproxy/ ACCESS,ISDIR
/tmp/ ACCESS,ISDIR haproxy
/tmp/haproxy/ ACCESS,ISDIR
/tmp/ CLOSE_NOWRITE,CLOSE,ISDIR haproxy
/tmp/haproxy/ CLOSE_NOWRITE,CLOSE,ISDIR
/tmp/haproxy/ CREATE haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/haproxy/ OPEN haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/ CREATE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040175033708
/tmp/ OPEN .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040175033708
/tmp/ CLOSE_WRITE,CLOSE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040175033708
/tmp/haproxy/ CREATE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401651278905
/tmp/haproxy/ OPEN .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401651278905
/tmp/haproxy/ CLOSE_WRITE,CLOSE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401651278905
/tmp/ MOVED_FROM .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040175033708
/tmp/haproxy/ MOVED_TO .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401651278905
/tmp/haproxy/ DELETE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401651278905
/tmp/ CREATE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401034198605
/tmp/ OPEN .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401034198605
/tmp/ ATTRIB .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401034198605
/tmp/ MODIFY .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401034198605
/tmp/ CLOSE_WRITE,CLOSE .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401034198605
/tmp/ MOVED_FROM .haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d40401034198605
/tmp/haproxy/ MOVED_TO haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/haproxy/ CLOSE_NOWRITE,CLOSE haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/haproxy/ OPEN haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/haproxy/ ACCESS haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/haproxy/ CLOSE_NOWRITE,CLOSE haproxy.cfg.540fce12-1e3c-4061-98cb-33e5475d4040
/tmp/ OPEN,ISDIR haproxy
/tmp/haproxy/ OPEN,ISDIR
/tmp/ ACCESS,ISDIR haproxy
/tmp/haproxy/ ACCESS,ISDIR
/tmp/ ACCESS,ISDIR haproxy
/tmp/haproxy/ ACCESS,ISDIR
/tmp/ CLOSE_NOWRITE,CLOSE,ISDIR haproxy
/tmp/haproxy/ CLOSE_NOWRITE,CLOSE,ISDIR

[dkorunic]

@Slair1 I would try with with TMPDIR env variable for dataplaneapi service, since renameio used respects that variable, ie:

export TMPDIR=/etc/haproxy/tmp

[dkorunic]

@Slair1 Any news here? Also, I am assuming that your HAProxy and Dataplaneapi services are not running in a container, as it looks like TMPDIR was set?