Bug 426122 - selinux thorougly breaks spamassasin
selinux thorougly breaks spamassasin
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2007-12-18 12:54 EST by Michal Jaegermann
Modified: 2008-01-30 14:05 EST (History)
0 users

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-30 14:05:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-12-18 12:54:01 EST
Description of problem:

This is possibly the same issue as bug 425983 but I am not entirely

Selinux in a default configuration spams log files with messages
like that:

setroubleshoot: #012    SELinux is preventing the spamd daemon from reading
users' home directories.#012

That would be only an annoyance if not that detail that selinux
actually breaks operation of a bayes filter, user preferences, white
listing... making spamassasin totally ineffective.

'sealert -l ...' advises to run 'setsebool -P spamd_enable_home_dirs=1'.
The catch is that this was done quite a while ago and
'getsebool spamd_enable_home_dirs' produces:

spamd_enable_home_dirs --> on

This does not help at all and selinux whining continues.

The installation happens to be recently redone "from scratch"
(with selinux left in a default state for new installations and
that, quite possibly, is a rather bad move).  After that
home directores were restored from a backup followed by
'restorecon -R /home'.  Everything in mine ~/.spamassasin is listed
as "unconfined_u:object_r:unconfined_home_t:s0", which does look
somewhat suspsicious, but 'restorecon -R -v -n ...' on that directory
is silent.  It is not clear to me what else could be done.

The only saving grace is that on that particular machine a mail
traffic is pretty limited.

sealert produce reports which looks like that:

    SELinux is preventing the spamd daemon from reading users' home directories.
Detailed Description
    SELinux has denied the spamd daemon access to users' home directories.
    Someone is attempting to access your home directories via your spamd daemon.
   If you only setup spamd to share non-home directories, this probably signals
   a intrusion attempt.

Allowing Access
    If you want spamd to share home directories you need to turn on the
    spamd_enable_home_dirs boolean: "setsebool -P spamd_enable_home_dirs=1"

    The following command will allow this access:
    setsebool -P spamd_enable_home_dirs=1

Additional Information

Source Context                unconfined_u:system_r:spamd_t:s0
Target Context                unconfined_u:object_r:unconfined_home_t:s0
Target Objects                None [ file ]
Affected RPM Packages
Policy RPM                    selinux-policy-3.0.8-64.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.spamd_enable_home_dirs
Host Name                     some.host
Platform                      Linux some.host #1
                              SMP Wed Nov 21 18:51:08 EST 2007 i686 athlon
Alert Count                   59
First Seen                    Sat Dec 15 12:52:40 2007
Last Seen                     Tue Dec 18 10:28:59 2007
Local ID                      16fbf9f4-d46e-4aea-a824-c204589cbbca
Line Numbers

Raw Audit Messages

avc: denied { create } for comm=spamd name=auto-
whitelist.lock.some.host.29517 pid=29517
scontext=unconfined_u:system_r:spamd_t:s0 tclass=file

Version-Release number of selected component (if applicable):

How reproducible:
all the time - unfortunately
Comment 1 Michal Jaegermann 2007-12-20 13:34:59 EST
Immediately after updates to 3.0.8-68.fc8 for selinux-policy,
selinux-policy-devel and selinux-policy-targeted packages I got
a long spate of "SELinux is preventing the spamd daemon from
reading users' home directories.#012".
'getsebool spamd_enable_home_dirs' still shows "on".

BTW - what all these "invalid" in /var/log/messages are supposed
to mean?

kernel: security:  context unconfined_u:unconfined_r:loadkeys_t:s0 is invalid
dbus: avc:  received policyload notice (seqno=2)
yum: Updated: selinux-policy-targeted - 3.0.8-68.fc8.noarch
yum: Updated: logwatch - 7.3.6-12.fc8.noarch
yum: Updated: policycoreutils-gui - 2.0.33-2.fc8.i386
kernel: security:  context unconfined_u:unconfined_r:loadkeys_t:s0 is invalid
dbus: avc:  received policyload notice (seqno=3)
kernel: security:  context unconfined_u:unconfined_r:loadkeys_t:s0 is invalid
dbus: avc:  received policyload notice (seqno=4)
restorecond: terminated
restorecond: Will not restore a file with more than one hard link
(/etc/resolv.conf) Success

Does the above means that new selinux policies were successfully
applied or not?

I had to switch selinux to "Permissive" for now or otherwise
spamasassin is practically broken.  Equally well I can just
switch selinux off.  Any real trouble is now just masked by
a flood of spurious alarms.

Comment 2 Daniel Walsh 2007-12-26 11:46:28 EST
Please try selinux-policy-3.0.8-72.fc8

Should be fixed there.
Comment 3 Michal Jaegermann 2007-12-26 14:20:21 EST
>  Please try selinux-policy-3.0.8-72.fc8

So far, with packages grabbed from updates-testing, the problem
with spamassassin seems to be gone (although testing at this moment
was very light).

During an update the following showed up:

kernel: security:  context unconfined_u:unconfined_r:loadkeys_t:s0 is invalid
kernel: security:  context unconfined_u:unconfined_r:loadkeys_t:s0 is invalid

and I have no idea why and from where this is coming.
Comment 4 Daniel Walsh 2007-12-31 11:47:33 EST
Are you seeing SELINUX_ERR in /var/log/audit/audit.log?

Comment 5 Michal Jaegermann 2007-12-31 13:03:21 EST
> Are you seeing SELINUX_ERR in /var/log/audit/audit.log?

No, I do not.

First of all, as noted earlier, installing selinux-policy-3.0.8-72.fc8
resolved the issue.

When I dig through audit.log I can see older lines of that sort:

type=AVC msg=audit(1197748351.287:240): avc:  denied  { getattr } for  pid=29359
comm="spamd" path="/home/michal/.spamassassin/user_prefs" dev=sda8 ino=1405416
tcontext=unconfined_u:object_r:unconfined_home_t:s0 tclass=file
type=SYSCALL msg=audit(1197748351.287:240): arch=40000003 syscall=195 success=no
exit=-13 a0=83b2c48 a1=827e0c8 a2=ddbff4 a3=83b2c48 items=0 ppid=29357 pid=29359
auid=294 uid=0 gid=0 euid=294 suid=0 fsuid=294 egid=100 sgid=0 fsgid=100
tty=(none) comm="spamd" exe="/usr/bin/perl"
subj=unconfined_u:system_r:spamd_t:s0 key=(null)

with the last time-stamp on such lines from 2007-12-26,  but no 
SELINUX_ERR anywhere.
Comment 6 Daniel Walsh 2008-01-30 14:05:57 EST
Bulk closing a old selinux policy bugs that were in the modified state.  If the
bug is still not fixed.  Please reopen.

Note You need to log in before you can comment on or make changes to this bug.