Resolved SELinux block mod_security access to DBM file "/var/asl/data/msa/global"

[raytracy]

CentOS 7.5 + Plesk 17.5.3

My mod_security throw a lot of error in log when I upgraded from 7.4 to 7.5:

Message: collections_remove_stale: Failed to access DBM file "/var/asl/data/msa/global": Permission denied
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client %s] ModSecurity: %s%s [uri "%s"]%s
Apache-Handler: proxy:unix:///var/www/vhosts/system/idngirl.com.tw/php-fpm.sock|fcgi://127.0.0.1:9000

And there are SELinux error in /var/log/messages:

May 16 11:11:45 migo-blue setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/asl/data/msa/global.dir. For complete SELinux messages run: sealert -l a63b5e2f-db5c-4791-bbaf-37d46cd5d393
May 16 11:11:45 migo-blue python: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/asl/data/msa/global.dir.#012#012***** Plugin catchall_labels (83.8 confidence) suggests *******************#012#012If you want to allow httpd to have getattr access on the global.dir file#012Then you need to change the label on /var/asl/data/msa/global.dir#012Do#012# semanage fcontext -a -t FILE_TYPE '/var/asl/data/msa/global.dir'#012where FILE_TYPE is one of the following: (....there are a lots of file type follow...)

It seems setenforce 0 could stop error in mod_security log, but still produce a lots of SELinux event.

I have try these command:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd
semodule -i my-httpd.pp
ausearch -x /usr/sbin/httpd --raw | audit2allow -D -M my-httpd
semodule -i my-httpd.pp
plesk repair installation -y (which help to restore SELinux context)

But did not solve this problem



How can I fix this issue with SELinux enforced?
(What is correct SELinux FILE_TYPE for /var/asl/data/msa/global.dir?)

 

[IgorG]

Yes, it is known issue and this issue on Atomic side. We tried to contact them in scope of our internal report PPPM-6202 but looks like that issue is still not fixed.
Try to as assistance from Atomic support.

 

[G J Piper]

And there are SELinux error in /var/log/messages:

May 16 11:11:45 migo-blue setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/asl/data/msa/global.dir. For complete SELinux messages run: sealert -l a63b5e2f-db5c-4791-bbaf-37d46cd5d393
May 16 11:11:45 migo-blue python: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/asl/data/msa/global.dir.#012#012***** Plugin catchall_labels (83.8 confidence) suggests *******************#012#012If you want to allow httpd to have getattr access on the global.dir file#012Then you need to change the label on /var/asl/data/msa/global.dir#012Do#012# semanage fcontext -a -t FILE_TYPE '/var/asl/data/msa/global.dir'#012where FILE_TYPE is one of the following: (....there are a lots of file type follow...)

How can I fix this issue with SELinux enforced?
(What is correct SELinux FILE_TYPE for /var/asl/data/msa/global.dir?)

You need to first run this, as it requests in the log:

sealert -l a63b5e2f-db5c-4791-bbaf-37d46cd5d393

It will give you the exact codes you need to run to add the correct SELinux policy rules for this specific error case, fixing it for the future.
Then, keep going through your logs and do the same for every case of sealert it gives you. After a bit you'll have all your special rules entered and you can set it to enforcing safely.

Also, when it gives you code like this to run:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd

change it slightly for each one, in case it names your rules identically, overwriting some that came before but had a slightly different rule -- like this:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd-uniquename

 

[raytracy]

Yes, it is known issue and this issue on Atomic side. We tried to contact them in scope of our internal report PPPM-6202 but looks like that issue is still not fixed.
Try to as assistance from Atomic support.

But I have another two Onyx box with same configuration both of them work well with Atomic rules and not produce this SELlinux error.

I have try to compare the file permission and context, but did not find any difference.

 

[raytracy]

You need to first run this, as it requests in the log:

sealert -l a63b5e2f-db5c-4791-bbaf-37d46cd5d393

It will give you the exact codes you need to run to add the correct SELinux policy rules for this specific error case, fixing it for the future.
Then, keep going through your logs and do the same for every case of sealert it gives you. After a bit you'll have all your special rules entered and you can set it to enforcing safely.

Also, when it gives you code like this to run:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd

change it slightly for each one, in case it names your rules identically, overwriting some that came before but had a slightly different rule -- like this:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd-uniquename

When i ran the sealert -l command, I got the following error:

sealert -l a63b5e2f-db5c-4791-bbaf-37d46cd5d393

Error
query_alerts error (1003): id (a63b5e2f-db5c-4791-bbaf-37d46cd5d393) not found

a63b5e2f-db5c-4791-bbaf-37d46cd5d393 was the last SELinux alert I found in /var/log/message, I have try to find previous alert with sealert comment, but got similar result as above.

 

[G J Piper]

When i ran the sealert -l command, I got the following error:

sealert -l a63b5e2f-db5c-4791-bbaf-37d46cd5d393

Error
query_alerts error (1003): id (a63b5e2f-db5c-4791-bbaf-37d46cd5d393) not found

a63b5e2f-db5c-4791-bbaf-37d46cd5d393 was the last SELinux alert I found in /var/log/message, I have try to find previous alert with sealert comment, but got similar result as above.

You have to run the command your log gives you, but it does seem to expire. I would look in your logs and run the last ones it gives you.

 

[raytracy]

This issues has been solved by Atomicorp KB.