This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 187974 - selinux denials of spamd reading files in /var/lib/spamassassin/
selinux denials of spamd reading files in /var/lib/spamassassin/
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: spamassassin (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-04 21:23 EDT by David Baron
Modified: 2007-11-30 17:11 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-17 13:48:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
A patch to fix it. (1.76 KB, patch)
2006-11-07 22:50 EST, Takanori MATSUURA
no flags Details | Diff

  None (edit)
Description David Baron 2006-04-04 21:23:07 EDT
Description of problem:  with the recent selinux and spamassassin updates to FC5
(which I picked up at the same time last week), there have started to be selinux
denials of spamd, three at a time, when spamd starts:

type=AVC msg=audit(1144179464.345:5): avc:  denied  { search } for  pid=1768
comm="spamd" name="lib" dev=hda3 ino=423490
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_lib_t:s0
tclass=dir
type=SYSCALL msg=audit(1144179464.345:5): arch=40000003 syscall=195 success=no
exit=-13 a0=97843b0 a1=93dd0c8 a2=9bfff4 a3=97843b0 items=1 pid=1768
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1144179464.345:5):  cwd="/"
type=PATH msg=audit(1144179464.345:5): item=0
name="/var/lib/spamassassin/3.001001" flags=1
type=AVC msg=audit(1144179464.753:6): avc:  denied  { search } for  pid=1768
comm="spamd" name="lib" dev=hda3 ino=423490
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_lib_t:s0
tclass=dir
type=SYSCALL msg=audit(1144179464.753:6): arch=40000003 syscall=195 success=no
exit=-13 a0=97843b0 a1=93dd0c8 a2=9bfff4 a3=97843b0 items=1 pid=1768
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1144179464.753:6):  cwd="/"
type=PATH msg=audit(1144179464.753:6): item=0
name="/var/lib/spamassassin/3.001001/languages" flags=101
type=AVC msg=audit(1144179466.234:7): avc:  denied  { search } for  pid=1768
comm="spamd" name="lib" dev=hda3 ino=423490
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_lib_t:s0
tclass=dir
type=SYSCALL msg=audit(1144179466.234:7): arch=40000003 syscall=195 success=no
exit=-13 a0=97843b0 a1=93dd0c8 a2=9bfff4 a3=97843b0 items=1 pid=1768
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1144179466.234:7):  cwd="/"
type=PATH msg=audit(1144179466.234:7): item=0
name="/var/lib/spamassassin/3.001001/triplets.txt" flags=1

I'm not sure what this effects, but having selinux prevent spamd from doing
things seems like it could break something.

Version-Release number of selected component (if applicable):
spamassassin-3.1.1-1.fc5
selinux-policy-2.2.25-3.fc5
selinux-policy-targeted-2.2.25-3.fc5

How reproducible:  Always (when spamd starts/restarts).

Steps to Reproduce:
1. tail -f /var/log/audit.log
2. /sbin/service spamassassin restart
  
Actual results: selinux denials

Expected results: no selinux denials

Additional information:
As a note, the directory /var/lib/spamassassin/ does not exist.  And the files
in question live in /usr/share/spamassassin/ ... which is why I'm filing this as
a bug on spamassassin rather than selinux-policy-targeted.
Comment 1 Volnei 2006-05-26 10:24:46 EDT
The problem occour yet and with this versions too

spamassassin-3.1.1-1.fc5
selinux-policy-2.2.40-1.fc5
selinux-policy-targeted-2.2.40-1.fc5
selinux-policy-targeted-2.2.40-1.fc5

ype=AVC msg=audit(1148584813.611:3689): avc:  denied  { write } for  pid=11827
comm="spamd" name="vcputtini" dev=sda2 ino=2125761
scontext=user_u:system_r:spamd_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
type=SYSCALL msg=audit(1148584813.611:3689): arch=40000003 syscall=39 success=no
exit=-13 a0=a855f40 a1=1c0 a2=d7d5c8 a3=a855f40 items=1 pid=11827 auid=500 uid=0
gid=0 euid=501 suid=0 fsuid=501 egid=12 sgid=0 fsgid=12 comm="spamd"
exe="/usr/bin/perl"
type=PATH msg=audit(1148584813.611:3689): item=0
name="/home/vcputtini/.spamassassin" flags=10  inode=2125761 dev=08:02
mode=040755 ouid=501 ogid=12 rdev=00:00
type=AVC msg=audit(1148584813.623:3690): avc:  denied  { write } for  pid=11827
comm="spamd" name="vcputtini" dev=sda2 ino=2125761
scontext=user_u:system_r:spamd_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
type=SYSCALL msg=audit(1148584813.623:3690): arch=40000003 syscall=39 success=no
exit=-13 a0=a855f40 a1=1c0 a2=d7d5c8 a3=a855f40 items=1 pid=11827 auid=500 uid=0
gid=0 euid=501 suid=0 fsuid=501 egid=12 sgid=0 fsgid=12 comm="spamd"
exe="/usr/bin/perl"
type=PATH msg=audit(1148584813.623:3690): item=0
name="/home/vcputtini/.spamassassin" flags=10  inode=2125761 dev=08:02
mode=040755 ouid=501 ogid=12 rdev=00:00
type=AVC msg=audit(1148584816.195:3691): avc:  denied  { write } for  pid=11827
comm="spamd" name="vcputtini" dev=sda2 ino=2125761
scontext=user_u:system_r:spamd_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
type=SYSCALL msg=audit(1148584816.195:3691): arch=40000003 syscall=39 success=no
exit=-13 a0=a935a18 a1=1c0 a2=d7d5c8 a3=a935a18 items=1 pid=11827 auid=500 uid=0
gid=0 euid=501 suid=0 fsuid=501 egid=12 sgid=0 fsgid=12 comm="spamd"
exe="/usr/bin/perl"
type=PATH msg=audit(1148584816.195:3691): item=0
name="/home/vcputtini/.spamassassin" flags=10  inode=2125761 dev=08:02
mode=040755 ouid=501 ogid=12 rdev=00:00
type=AVC msg=audit(1148584890.259:3704): avc:  denied  { write } for  pid=11827
comm="spamd" name="vcputtini" dev=sda2 ino=2125761
scontext=user_u:system_r:spamd_t:s0 tcontext=root:object_r:user_home_dir_t:s0
tclass=dir
type=AVC msg=audit(1148584890.259:3704): avc:  denied  { add_name } for 
pid=11827 comm="spamd" name=".spamassassin" scontext=user_u:system_r:spamd_t:s0
tcontext=root:object_r:user_home_dir_t:s0 tclass=dir
type=SYSCALL msg=audit(1148584890.259:3704): arch=40000003 syscall=39
success=yes exit=0 a0=a931ee8 a1=1c0 a2=d7d5c8 a3=a931ee8 items=1 pid=11827
auid=500 uid=0 gid=0 euid=501 suid=0 fsuid=501 egid=12 sgid=0 fsgid=12
comm="spamd" exe="/usr/bin/perl"
type=PATH msg=audit(1148584890.259:3704): item=0
name="/home/vcputtini/.spamassassin" flags=10  inode=2125761 dev=08:02
mode=040755 ouid=501 ogid=12 rdev=00:00
type=AVC msg=audit(1148584890.263:3705): avc:  denied  { write } for  pid=11827
comm="spamd" name=".spamassassin" dev=sda2 ino=2125806
scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
type=AVC msg=audit(1148584890.263:3705): avc:  denied  { add_name } for 
pid=11827 comm="spamd" name="user_prefs" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir
type=AVC msg=audit(1148584890.263:3705): avc:  denied  { create } for  pid=11827
comm="spamd" name="user_prefs" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:object_r:user_home_dir_t:s0 tclass=file
type=SYSCALL msg=audit(1148584890.263:3705): arch=40000003 syscall=5 success=yes
exit=9 a0=a1247e8 a1=8241 a2=1b6 a3=8241 items=1 pid=11827 auid=500 uid=0 gid=0
euid=501 suid=0 fsuid=501 egid=12 sgid=0 fsgid=12 comm="spamd" exe="/usr/bin/perl"
type=PATH msg=audit(1148584890.263:3705): item=0
name="/home/vcputtini/.spamassassin/user_prefs" flags=310  inode=2125806
dev=08:02 mode=040700 ouid=501 ogid=12 rdev=00:00
type=AVC msg=audit(1148584890.263:3706): avc:  denied  { ioctl } for  pid=11827
comm="spamd" name="user_prefs" dev=sda2 ino=2125815
scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=file
Comment 2 Paul Howarth 2006-05-26 10:32:36 EDT
Do you have the spamd_enable_home_dirs SELinux boolean set?
Comment 3 Daniel Walsh 2006-05-26 10:35:24 EDT
Tell me again why spamd needs to write to users homedirectories?  This just
seems wrong.

setsebool -P spamd_enable_home_dirs=1 

should fix this problem.
Comment 4 Justin Mason 2006-05-26 10:42:59 EDT
/var/lib/spamassassin is the directory tree created by "sa-update" -- the (new)
SA update script.
Comment 5 Andreas Thienemann 2006-05-26 10:46:35 EDT
(In reply to comment #3)
> Tell me again why spamd needs to write to users homedirectories?  This just
> seems wrong.

AFAIK it doesen't _need_ to write to the user's homedir.
But spamd can be configured to work run systemwide, but get configuration from
each users homedir and also store per-user bayes-db and auto-whitelist in their
homedirs.

Thus the write necessity.
Comment 6 Daniel Walsh 2006-05-26 10:53:23 EDT
Blah,

I don't like system space being able to write to users home directories.  System
Space is where the bad guys live.  Userspace is where the good stuff is.

As far as /var/lib:
Is this something the fedora package changes or is this something new?  Does
spamd need to read files in /var/lib?  Does it need to write them there? 
Comment 7 Andreas Thienemann 2006-05-26 11:03:35 EDT
(In reply to comment #6)
> I don't like system space being able to write to users home directories.  System
> Space is where the bad guys live.  Userspace is where the good stuff is.
Understandable.

I haven't looked at recent spamassassin packages, but AFAIK it should be
possible to limit spamd to read/write data only from ~/.spamassassin/.

Maybe this is good enough as a compromise?
Comment 8 Daniel Walsh 2006-05-26 11:28:25 EDT
Yes current strict policy has this constraint.   The problem here is that
maintaining file context on user homedirs is difficult.  Since they tend to do
wacky stuff there :^).  Like use NFS/AFT/Samba.  Or setup random symlinks.  Or
even worse not have these directories created in the RPM Package.  So labeling
gets difficult.  restorecond can help with some of these things, but I like to
avoid them in targeted policy.  Currenly we only have public_html, being maintained.
Comment 9 Paul Howarth 2006-05-26 11:37:13 EDT
(In reply to comment #6)
> I don't like system space being able to write to users home directories.  System
> Space is where the bad guys live.  Userspace is where the good stuff is.
> 
> As far as /var/lib:
> Is this something the fedora package changes or is this something new?  Does
> spamd need to read files in /var/lib?  Does it need to write them there? 

I use spamassassin with virtual users; in /etc/sysconfig/spamassassin I have:
SPAMDOPTIONS="-d -c -m5 -x --virtual-config-dir=/home/spamassassin/%u -H" 

I would very much like to have the user preferences/bayes files somewhere is
"system space" (/home/spamassassin isn't a real user home directory but has file
contexts as if it was). However, I couldn't figure out a suitable location to
put these files. I tried making a directory /var/spool/spamsassassin at first
but SELinux was much less happy there than where I have it now. So where
*should* I have this data to keep it in system space?
Comment 10 Paul Howarth 2006-07-14 13:31:00 EDT
(In reply to comment #9)
> (In reply to comment #6)
> > I don't like system space being able to write to users home directories.  System
> > Space is where the bad guys live.  Userspace is where the good stuff is.
> > 
> > As far as /var/lib:
> > Is this something the fedora package changes or is this something new?  Does
> > spamd need to read files in /var/lib?  Does it need to write them there? 
> 
> I use spamassassin with virtual users; in /etc/sysconfig/spamassassin I have:
> SPAMDOPTIONS="-d -c -m5 -x --virtual-config-dir=/home/spamassassin/%u -H" 
> 
> I would very much like to have the user preferences/bayes files somewhere is
> "system space" (/home/spamassassin isn't a real user home directory but has file
> contexts as if it was). However, I couldn't figure out a suitable location to
> put these files. I tried making a directory /var/spool/spamsassassin at first
> but SELinux was much less happy there than where I have it now. So where
> *should* I have this data to keep it in system space?

I note that the spamassassin policy now has spamd_spool_t for
/var/spool/spamassassin(/.*)?

Is the intended use of this for virtual users as I described above?
Comment 11 Takanori MATSUURA 2006-11-07 22:50:47 EST
Created attachment 140624 [details]
A patch to fix it.

Sorry for ading a comment to already closed bug.

This patch changes the local state dir from /var/lib/spamassassin to
/var/spool/spamassain.

As far as I tested, sa-update'ed SapmAssassin rules seems to work fine.
Comment 12 Warren Togami 2006-12-14 22:21:03 EST
Crap.  I don't remember reading this before today.

Reading and writing to $HOME/.spamassassin/* is the *NORMAL* method of operation
for spamassassin, and it always has been for many years now.  Our SELinux policy
is broken by default if we don't support this.

Need to verify if this is working or not in RHEL5 by default.
Comment 13 Nicolas Mailhot 2006-12-15 03:49:31 EST
(In reply to comment #6)

> As far as /var/lib:
> Is this something the fedora package changes or is this something new?

It's somehow a new upstream feature where updated rules can be distributed
separately from the main engine, so the sa people do not have to do full
releases every time a spammer thinks of a new trick (similar to new AV checksums)

> Does
> spamd need to read files in /var/lib?  Does it need to write them there?

sa needs read access to /var/lib/spamassassin, the rules updating is supposed to
be done by a super-user (allowing sa to self-update its ruleset would of course
be dangerous)
 
IMHO /var/lib and not /var/cache or /var/spool is the right place for this kind
of stuff
Comment 14 Daniel Walsh 2006-12-15 09:39:12 EST
Warren, There is a boolean that allows spamassassin to operate on homedirs.
spamd_enable_home_dirs, and it defaults to True.

I still don't believe this is a good design.  Allowing system services to write
to  users homedir's is a broken design.
Comment 15 Warren Togami 2006-12-15 10:13:54 EST
dwalsh,

Does spamassassin and spamd have access to read from /var/lib/spamassassin?
Comment 16 Kenneth Porter 2006-12-15 11:21:59 EST
How is spamd's writing Bayes information to one's home directory different from
procmail writing spooled mail to one's local folders? How does selinux handle
procmail and folders?
Comment 17 Daniel Walsh 2006-12-18 16:23:01 EST
Warren, It does now.  selinux-policy-2.4.6-15

Kenneth, it is no different.  but that does not mean I like procmail doing this
anymore than spamassissin.  :^)

Comment 18 Daniel Walsh 2006-12-20 13:33:46 EST
Fixed in selinux-policy-2.4.6-15

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