Re: [CentOS] Spamassassin vs. SELinux trouble

2017-12-14 Thread Nicolas Kovacs 
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

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Spamassassin vs. SELinux trouble

2017-12-12 Thread Gordon Messmer 

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 Contextsystem_u:system_r:spamd_t:s0
Target Contextsystem_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.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Spamassassin vs. SELinux trouble

2017-12-12 Thread Kenneth Porter 

On 12/12/2017 4:37 AM, Nicolas Kovacs wrote:

SELinux is preventing /usr/bin/perl from 'read, write' accesses on the
file/var/log/spamassassin/.spamassassin/bayes_toks.


What user is this running as? Who has /var/log/spamassassin as the home 
directory?


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Spamassassin vs. SELinux trouble

2017-12-12 Thread Peter Kjellström 
On Tue, 12 Dec 2017 13:37:30 +0100
Nicolas Kovacs  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 Contextsystem_u:system_r:spamd_t:s0
> Target Contextsystem_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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Spamassassin vs. SELinux trouble

2017-12-12 Thread Nicolas Kovacs 
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 Contextsystem_u:system_r:spamd_t:s0
Target Contextsystem_u:object_r:var_log_t:s0
Target Objects
/var/log/spamassassin/.spamassassin/bayes_toks [
  file ]
Source7370616D64206368696C64
Source Path   /usr/bin/perl
Port  
Host  
Source RPM Packages   perl-5.16.3-292.el7.x86_64
Target RPM Packages
Policy RPMselinux-policy-3.13.1-166.el7_4.7.noarch
Selinux Enabled   True
Policy Type   targeted
Enforcing ModeEnforcing
...

--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
-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SpamAssassin vs. SELinux

2017-10-06 Thread Nicolas Kovacs 
Le 06/10/2017 à 08:50, Nicolas Kovacs a écrit :
> Usually sealert's suggestions are to the point and work perfectly.
> Except in this case it doesn't. Here's what I get:
> 
> # ausearch -c '7370616D64206368696C64' --raw | audit2allow -M
> my-7370616D64206368696C64
> Nothing to do
> 
> Any suggestions?

I'll answer that myself, since I just found the culprit.

# setsebool -P spamd_enable_home_dirs 1

Boolean did the trick. Looks like this is not in setroubleshoot's database.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] SpamAssassin vs. SELinux

2017-10-06 Thread Nicolas Kovacs 
Hi,

I just installed SpamAssassin on two servers running CentOS 7 and
Postfix. One is my sandbox server for experimenting, the other one is
the server that hosts my company's web site, blog, mail, etc.

So far, SpamAssassin seems to work as expected. I sent a test mail,
which was duly flagges as [SPAM], and I already see the odd incoming
spam message correctly flagged as [SPAM].

For testing purposes, I switched SELinux to permissive mode (usually I
activate SELinux for everything).

It looks like it's causing a bit of a problem here.

# sealert -a /var/log/audit/audit.log

And here's what I get.

--8<--
SELinux is preventing /usr/bin/perl from create access on the directory
.spamassassin.

*  Plugin catchall (100. confidence) suggests   *

If you believe that perl should be allowed create access on the
.spamassassin directory 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
...
--8<--

Usually sealert's suggestions are to the point and work perfectly.
Except in this case it doesn't. Here's what I get:

# ausearch -c '7370616D64206368696C64' --raw | audit2allow -M
my-7370616D64206368696C64
Nothing to do

Any suggestions?

Cheers from the sunny South of France,

Niki Kovacs

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos