Hi,
Spamassassin has been working nicely on my main server running CentOS 7 and Postfix. SELinux is activated (Enforcing).
Since the most recent update (don't know if it's related to it though) I'm getting the following SELinux error.
--8<----------------------------------------------------------------- SELinux is preventing /usr/bin/perl from 'read, write' accesses on the file /var/log/spamassassin/.spamassassin/bayes_toks.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that perl should be allowed read write access on the bayes_toks file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c '7370616D64206368696C64' --raw | audit2allow -M my-7370616D64206368696C64 # semodule -i my-7370616D64206368696C64.pp
Additional Information: Source Context system_u:system_r:spamd_t:s0 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/spamassassin/.spamassassin/bayes_toks [ file ] Source 7370616D64206368696C64 Source Path /usr/bin/perl Port <Unknown> Host <Unknown> Source RPM Packages perl-5.16.3-292.el7.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-166.el7_4.7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing ...
--8<-----------------------------------------------------------------
Unfortunately the suggested solution does not work, e. g. the following command returns nothing:
# ausearch -c '7370616D64206368696C64' --raw
Now I'm clueless. Any suggestions?
Cheers,
Niki
On Tue, 12 Dec 2017 13:37:30 +0100 Nicolas Kovacs info@microlinux.fr wrote:
Hi,
Spamassassin has been working nicely on my main server running CentOS 7 and Postfix. SELinux is activated (Enforcing).
Since the most recent update (don't know if it's related to it though) I'm getting the following SELinux error.
--8<----------------------------------------------------------------- SELinux is preventing /usr/bin/perl from 'read, write' accesses on the file /var/log/spamassassin/.spamassassin/bayes_toks.
...
Additional Information: Source Context system_u:system_r:spamd_t:s0 Target Context system_u:object_r:var_log_t:s0
This seems like it should have been denied. You probably don't want system_r:spamd_t to write to var_log_t.
I don't have access to a c7 with spamassasin right now but would guess that /var/log/spamassassin/.spamassassin/bayes_toks should have been a different context (something like spam_log_t).
You can use "ls -Z" on /var/log/spamassassin to find out what context the top level dir has. Then use restorcon (if the policy has the correct data but the real world file/dir is wrong). chcon can be used to test a change but for a permanent fix you'll have to add it to the policy (file context listing).
/Peter K
On 12/12/2017 04:37 AM, Nicolas Kovacs wrote:
Spamassassin has been working nicely on my main server running CentOS 7 and Postfix. SELinux is activated (Enforcing). ... SELinux is preventing /usr/bin/perl from 'read, write' accesses on the file /var/log/spamassassin/.spamassassin/bayes_toks. ... Source Context system_u:system_r:spamd_t:s0 Target Context system_u:object_r:var_log_t:s0
You may have had a custom context set on /var/log/spamassassin or a sub-path in the past, overwritten by a recent update. That's a normal occurrence if you set context using chcon rather than "semanage fcontext". The latter is persistent; the former is not.
Spamassassin can write to /var/lib/spamassassin, which makes that a more suitable location for bayes_toks than /var/log. However, if you'd prefer to keep your bayes_toks file where it is, use:
semanage fcontext -a -t spamd_var_lib_t /var/log/spamassassin/.spamassassin restorecon -Rv /var/log/spamassassin/.spamassassin
That should set a new context for the path in your local policy, and then apply that context. Afterward, spamd should be able to write to that path.
Le 12/12/2017 à 21:25, Gordon Messmer a écrit :
You may have had a custom context set on /var/log/spamassassin or a sub-path in the past, overwritten by a recent update. That's a normal occurrence if you set context using chcon rather than "semanage fcontext". The latter is persistent; the former is not.
Spamassassin can write to /var/lib/spamassassin, which makes that a more suitable location for bayes_toks than /var/log. However, if you'd prefer to keep your bayes_toks file where it is, use:
semanage fcontext -a -t spamd_var_lib_t /var/log/spamassassin/.spamassassin restorecon -Rv /var/log/spamassassin/.spamassassin
Thanks very much. That got me on the right track, though I solved the problem a bit differently.
# semanage fcontext -a -t spamd_var_lib_t '/var/log/spamassassin(/.*)?' # restorecon -Rv /var/log/spamassassin/
That did the trick.
Cheers,
Niki
-
Gordon Messmer -
Kenneth Porter -
Nicolas Kovacs -
Peter Kjellström