Bug 187974

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

Do you have the spamd_enable_home_dirs SELinux boolean set?

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.

/var/lib/spamassassin is the directory tree created by "sa-update" -- the (new)
SA update script.

(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.

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? 

(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?

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.

(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?

(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?

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.

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.

(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

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.

dwalsh,

Does spamassassin and spamd have access to read from /var/lib/spamassassin?

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?

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.  :^)

Fixed in selinux-policy-2.4.6-15