I'm elevating this to HIGH because with no spam filtering I am being overwhelmed
with spam to the extent that it is difficult to get anything else done.

Note that until a policy update arrives, you can add the necessary permissions
locally to your policy via the sequence described in the EXAMPLE section of the
audit2allow(1) man page.  

Please try the policy on 

ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.9

If this works for you I will put it into fedora test.  This policy adds policy
for spamd.

(In reply to comment #3)
> Please try the policy on 
> 
> ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.9
> 
> If this works for you I will put it into fedora test.  This policy adds policy
> for spamd.

Thanks, Daniel. I've installed your new packages. I'll keep an eye on the mail
logs for half an hour or so and then report back.

Do I need to restart anything (postfix, spamassassin) once I've installed the
updates? Although it's only been a couple of minutes I'm seeing no improvements.

Okay, even with your new packages installed spam filtering is definitely still
not working. I can tell just by examining the headers of mail messages once
they've been delivered.

For example, here is an excerpt from /var/log/maillog:

Oct 20 15:00:40 excession postfix/smtpd[7584]: 7DA00431FB2:
client=excession.dzr[127.0.0.1]
Oct 20 15:00:40 excession postfix/cleanup[7587]: 7DA00431FB2:
message-id=<898101c5d57e$02cdd6fd$3eae975d@yj252n1>
Oct 20 15:00:40 excession postfix/qmgr[2225]: 7DA00431FB2:
from=<loretta_coloncw>, size=3107, nrcpt=1 (queue active)
Oct 20 15:00:40 excession postfix/local[7588]: 7DA00431FB2:
to=<darren.dzr>, orig_to=<darren@localhost>, relay=local,
delay=0, status=sent (delivered to command: IFS=' ' && exec /usr/bin/procmail
-f- || exit 75 #darren)
Oct 20 15:00:40 excession postfix/qmgr[2225]: 7DA00431FB2: removed

And here is the relevant part from /var/log/audit/audit.log:

type=AVC msg=audit(1129816840.688:655): avc:  denied  { search } for  pid=7593
comm="procmail" name="mail" dev=hda3 ino=1890406
scontext=system_u:system_r:postfix_local_t tcontext=system_u:object_r:etc_mail_t
tclass=dir
type=SYSCALL msg=audit(1129816840.688:655): arch=40000003 syscall=195 success=no
exit=-13 a0=90afa96 a1=bffaf104 a2=9b7ff4 a3=90add3a items=1 pid=7593
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500
fsgid=500 comm="procmail" exe="/usr/bin/procmail"
type=CWD msg=audit(1129816840.688:655):  cwd="/home/darren"
type=PATH msg=audit(1129816840.688:655): item=0
name="/etc/mail/spamassassin/spamassassin-spamc.rc" flags=1  inode=1890406
dev=03:03 mode=040755 ouid=0 ogid=0 rdev=00:00

(Well, I think that was the relevant bit of audit.log. I don't exactly
understand to well what that stuff means.)

Switch to permissive mode (/usr/sbin/setenforce 0), run for a little while to
collect the audit messages related to your issue, then follow the steps listed
in the EXAMPLE section of the audit2allow(1) man page to add the necessary
permissions to your policy locally, and attach the resulting local.te file here
for consideration in a policy update.

Okay, this is what I did.

# /usr/sbin/setenforce 0

Waited for about twenty minutes until I could see some mail that had definitely
been filtered through spamassassin. Then,

# cd /etc/selinux/targeted/src/policy/
# /usr/bin/audit2allow -i < /var/log/audit/audit.log >> domains/misc/local.te

I'll attach the local.te next.

However, if I understand what I've just done, I now will not be able to
determine whether any updates fix this problem as I have a local workaround in
place. How can I return my system to its former state (given that I was stupid
enough to not make a backup of the original local.te)?

Created attachment 120192 [details]
local.te (see previous comment)

First, you need to also do a 'make load' in the policy directory if you want the
regenerated policy with the new local.te to be loaded into your kernel for
enforcement (at which point you can switch back to enforcing mode and verify
that it all works).

Second, local.te is purely for your own local customizations, so you can empty
it out at any time if you want to re-test against pristine policy.  If you
already had some entries in it from prior customizations, you should be able to
distinguish the postfix bits from the rest based on the types.

Ok lets add this to your local.te file.

domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t)

Also attach your audit.log file 

What is causing these?  Might be a mislabeled file system or actual policy bugs.
allow cupsd_config_t lib_t:dir write;
allow cupsd_config_t usr_t:dir write;
allow cupsd_config_t var_t:dir create;
allow cupsd_config_t var_t:file { read write };
allow dhcpc_t tmp_t:chr_file read;
allow httpd_t jabber_client_port_t:tcp_socket name_connect;
allow httpd_t usr_t:dir write;
allow nmbd_t samba_log_t:dir remove_name;
allow ping_t locale_t:file read;
allow ping_t self:unix_dgram_socket create;

The transition to spamd should fix these.
allow postfix_local_t etc_mail_t:dir search;
allow postfix_local_t etc_mail_t:file { getattr read };

(In reply to comment #11)
> Ok lets add this to your local.te file.
> 
> domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t)

I'm assuming you want me to add that, do a 'make load' in the directory as per
comment #10, and then do a setenforce 1. Then I presume you want to know if spam
filtering starts working.

> Also attach your audit.log file 

No problem, I'll do that next. Again, I'm assuming you want the audit.log file
after the system has been running with the above changes for a couple of minutes.

> What is causing these?  Might be a mislabeled file system or actual policy bugs.
> allow cupsd_config_t lib_t:dir write;
> allow cupsd_config_t usr_t:dir write;
> allow cupsd_config_t var_t:dir create;
> allow cupsd_config_t var_t:file { read write };
> allow dhcpc_t tmp_t:chr_file read;
> allow httpd_t jabber_client_port_t:tcp_socket name_connect;
> allow httpd_t usr_t:dir write;
> allow nmbd_t samba_log_t:dir remove_name;
> allow ping_t locale_t:file read;
> allow ping_t self:unix_dgram_socket create;

I really don't know. The only one that seems related to anything I've been
working on is the jabber line, which is part of a PHP web application I'm
working on which sends messages out to jabber clients. I've no idea about any of
the others.

Daniel, I've realised that I may have misunderstood your comment #11. Did you
want me to first remove what audit2allow added to local.te and replace it with
domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t)? I simply added it,
but in retrospect I'm guessing that that will prove nothing with at least

allow postfix_local_t etc_mail_t:dir search;
allow postfix_local_t etc_mail_t:file { getattr read };

still in local.te.

Yes remove those lines.

You can remove httpd_t jabber line also, and turn on the boolean

setsebool -P httpd_can_network_connect=1

Okay, so local.te now only contains these two lines:

domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t);
setsebool -P httpd_can_network_connect=1;

I did 'make load' in the policy directory but got the following error:

domains/misc/local.te:7:ERROR 'syntax error' at token 'setsebool' on line 6451:
;
setsebool -P httpd_can_network_connect=1;
/usr/bin/checkpolicy:  error(s) encountered while parsing configuration
make: *** [/etc/selinux/targeted/policy/policy.19] Error 1

setsebool is a utility (a user command), not a policy statement.
Dan meant for you to run it, not add it to the local.te file.
By passing the -P, the new boolean value will be saved (in a "booleans" file
elsewhere in the policy tree) for reboots as well.

Re comment #16, thanks!

So, local.te now simply contains:

domain_auto_trans(postfix_local_t, spamd_exec_t, spamd_t);

I've done 'make load' in the policy directory, setenforce was already set to 1
from the previous round of changes. I'm assuming that's enough to have loaded
the new policy. I'll leave it for ten minutes or so and then attach my audit.log.

Okay, the new policy has been running for about 25 minutes. I can definitely
confirm that spam filtering is NOT working. Attaching audit.log.

Created attachment 120201 [details]
bzip2 of /var/log/audit/audit.log

audit.log is huge (6.6MB)! How come it isn't rotated like the rest of the log
files? Anyway, I've attached a bzip2ed version (299KB).

Dunno whether this is the same problem that hit me on my development install,
but I had to add the following to my local.te to get spamd to even start:

allow spamd_t default_t:lnk_file read;
allow spamd_t port_t:udp_socket name_bind;

(it's the latter that actually fixes the problem, I'm pretty sure; the former is
probably just a symptom of my having a soft-link for my ~/.spamassassin, but it
would be nice to have that into the policy as well)

Following a chat on IRC with Daniel Walsh I modified
/etc/selinux/targeted/src/policy/domains/misc/local.te to contain just this line:

r_dir_file(postfix_local_t, etc_mail_t);

and this has got spamassassin working 90%. However, Bayesian filtering is still
not working. For this to work, spamd needs to be able to read the Bayesian data
which is in ~/.spamassassin. The permissions on ~/.spamassassin are as follows:

$ ls -ldZ .spamassassin/
drwx------  darren   darren   user_u:object_r:user_home_t      .spamassassin/

$ ls -lZ .spamassassin/
-rw-------  darren   darren   user_u:object_r:user_home_t      auto-whitelist
-rw-------  darren   darren   user_u:object_r:user_home_t      bayes_seen
-rw-------  darren   darren   user_u:object_r:user_home_t      bayes_toks
-rw-rw-r--  darren   darren   user_u:object_r:user_home_t      old_bayes_seen
-rw-rw-r--  darren   darren   user_u:object_r:user_home_t      old_bayes_toks
-rw-r--r--  darren   darren   user_u:object_r:user_home_t      user_prefs

Since the selinux policy update, and since the modification to local.te, I am
seeing messages in /var/log/maillog like this:

Oct 21 16:46:35 excession spamd[2247]: connection from excession.dzr [127.0.0.1]
at port 40689
Oct 21 16:46:35 excession spamd[2247]: info: setuid to darren succeeded
Oct 21 16:46:35 excession spamd[2247]: Creating default_prefs
[/home/darren/.spamassassin/user_prefs]
Oct 21 16:46:35 excession spamd[2247]: Cannot write to
/home/darren/.spamassassin/user_prefs: Permission denied
Oct 21 16:46:35 excession spamd[2247]: Couldn't create readable default_prefs
for [/home/darren/.spamassassin/user_prefs]
Oct 21 16:46:36 excession spamd[2247]: processing message
<9b9801c5d652$11c16042$ce842dc8@frwpik1> for darren:500.
Oct 21 16:46:36 excession spamd[2247]: identified spam (5.6/5.0) for darren:500
in 0.2 seconds, 1670 bytes.
Oct 21 16:46:36 excession spamd[2247]: result: Y  5 -
DATE_IN_FUTURE_96_XX,FORGED_RCVD_HELO,INVALID_DATE,MSGID_DOLLARS,NO_OBLIGATION,NO_REAL_NAME,RCVD_BY_IP
scantime=0.2,size=1670,mid=<9b9801c5d652$11c16042$ce842dc8@frwpik1>,autolearn=no

Note that the last line is the spamassassin tests. This should include a
Bayesian score of the form BAYES_## but as you can see it doesn't because the
spamd could not access the Bayesian data in ~/.spamassassin.

If we compare a message from /var/log/maillog.1 from before the selinux policy
update we can see:

Oct 17 11:35:14 excession spamd[2491]: connection from excession.dzr [127.0.0.1]
at port 53984
Oct 17 11:35:14 excession spamd[2491]: info: setuid to darren succeeded
Oct 17 11:35:16 excession spamd[2491]: processing message
<57626485.0.16Oct2005224523-osrs-resellers-1041.net> for darren:500.
Oct 17 11:35:33 excession spamd[2491]: clean message (-3.4/5.0) for darren:500
in 19.1 seconds, 3161 bytes.
Oct 17 11:35:33 excession spamd[2491]: result: . -3 - AWL,BAYES_00
scantime=19.1,size=3161,mid=<57626485.0.16Oct2005224523-osrs-resellers-1041.net>,bayes=4.05883510135041e-09,autolearn=ham

I believe that this is an instance of the messages being written to audit.log
regarding this issue:

type=AVC msg=audit(1130150210.212:16477): avc:  denied  { search } for  pid=2247
comm="spamd" name="/" dev=hda5 ino=2 scontext=system_u:system_r:spamd_t
tcontext=system_u:object_r:home_root_t tclass=dir
type=SYSCALL msg=audit(1130150210.212:16477): arch=40000003 syscall=195
success=no exit=-13 a0=a419878 a1=97520c8 a2=9b7ff4 a3=a419878 items=1 pid=2247
auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500
comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1130150210.212:16477):  cwd="/"
type=PATH msg=audit(1130150210.212:16477): item=0
name="/home/darren/.spamassassin/user_prefs" flags=1  inode=2 dev=03:05
mode=040755 ouid=0 ogid=0 rdev=00:00

Obviously if I can provide more information please let me know.

Alexandre Oliva (oliva.unicamp.br)

The following looks like a labeling problem if this is indead a link in your
homedir it should be labeled user_home_t.
allow spamd_t default_t:lnk_file read;

What port is it trying to connect to?
allow spamd_t port_t:udp_socket name_bind;

I will allow spamd to seach home_root_t.

(In reply to comment #22)
> I will allow spamd to seach home_root_t.

Excellent. What should I add as a temporary workaround to local.te until the
next update?

My ~/.spamassassin is a link pointing outside my home dir, and even though /home
(another link) was properly labeled, the directory it pointed to wasn't.  Or
something along these lines.  Relabeling the pointed-to directory as home_root_t
and adding the following line to local.te (there you go, Darren :-) enabled it
to work again.

allow spamd_t home_root_t:dir search;


As for the port it's binding to, I've no idea of how to tell.  I'd think it's
for DNS resolution, for the several live blocking databases.  This is what gets
logged in audit.log:

type=AVC msg=audit(1129838891.100:70): avc:  denied  { name_bind } for  pid=2331
comm="spamd" src=21875 scontext=system_u:system_r:spamd_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1129838891.100:70): arch=40000003 syscall=102 success=no
exit=-13 a0=2 a1=bfff6b90 a2=745b500 a3=10 items=0 pid=2331 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=SOCKADDR msg=audit(1129838891.100:70): saddr=02005573000000000000000000000000
type=SOCKETCALL msg=audit(1129838891.100:70): nargs=3 a0=6 a1=8ba0a38 a2=10

Thanks, Alexandre. Unfortunately adding

allow spamd_t home_root_t:dir search;

to my local.te didn't work. After a suggestion from dwalsh on IRC I also tried

r_dir_file(spamd_t, user_home_t);

and that didn't do the trick either. I also tried both, and that too was no
help. This is what is being written to /var/log/maillog:

Oct 24 20:26:56 excession spamd[2248]: connection from excession.dzr [127.0.0.1]
at port 40421
Oct 24 20:26:56 excession spamd[2248]: info: setuid to darren succeeded
Oct 24 20:26:56 excession spamd[2248]: Creating default_prefs
[/home/darren/.spamassassin/user_prefs]
Oct 24 20:26:56 excession spamd[2248]: Cannot write to
/home/darren/.spamassassin/user_prefs: Permission denied
Oct 24 20:26:56 excession spamd[2248]: Couldn't create readable default_prefs
for [/home/darren/.spamassassin/user_prefs]
Oct 24 20:26:56 excession spamd[2248]: processing message
<1130181863.9090.0.camel> for darren:500.
Oct 24 20:26:57 excession spamd[2248]: clean message (0.0/5.0) for darren:500 in
0.2 seconds, 1862 bytes.
Oct 24 20:26:57 excession spamd[2248]: result: .  0 - RCVD_BY_IP
scantime=0.2,size=1862,mid=<1130181863.9090.0.camel>,autolearn=failed
Oct 24 20:26:57 excession postfix/local[13903]: BD61B431FB4:
to=<darren.dzr>, orig_to=<darren@localhost>, relay=local,
delay=1, status=sent (delivered to command: IFS=' ' && exec /usr/bin/procmail
-f- || exit 75 #darren)

However, I can't see anything being written to audit.log about this now (I just
watched what happened when a new mail message came in using "tail -f
/var/log/audit/audit.log"). Given that spamd is running as setuid darren when it
runs I don't think it is a permissions problem (of the chmod variety), but
surely if it was an selinux issue something would have been written to
audit.log. I'm stumped.

Adding

allow spamd_t user_home_dir_t:dir { getattr search };

to local.te worked! Thanks to dwalsh on IRC for the tip.

Sorry, but I've just realised something else. For Bayesian filtering spamd needs
to *read* ~/.spamassassin, which it now can. But for Bayesian autolearning it
also needs to be able to *write* to ~/.spamassassin.

This (from /var/log/maillog) shows Bayesian analysis working (note BAYES_00 in
the last line) but autolearning still failing (4th line and end of last line).

Oct 24 22:21:24 excession spamd[2247]: connection from excession.dzr [127.0.0.1]
at port 40860
Oct 24 22:21:24 excession spamd[2247]: info: setuid to darren succeeded
Oct 24 22:21:24 excession spamd[2247]: processing message
<435D501B.4030907.gr> for darren:500.
Oct 24 22:21:24 excession spamd[2247]: cannot write to
/home/darren/.spamassassin/bayes_journal, Bayes db update ignored: Permission denied
Oct 24 22:21:24 excession spamd[2247]: clean message (-2.4/5.0) for darren:500
in 0.4 seconds, 4748 bytes.
Oct 24 22:21:24 excession spamd[2247]: result: . -2 -
BAYES_00,MISSING_HEADERS,RCVD_BY_IP
scantime=0.4,size=4748,mid=<435D501B.4030907.gr>,bayes=0,autolearn=failed

I just upgraded to the latest from updates-released:

$ rpm -qa | grep selinux-policy | sort
selinux-policy-strict-1.27.1-2.11
selinux-policy-strict-sources-1.27.1-2.11
selinux-policy-targeted-1.27.1-2.11
selinux-policy-targeted-sources-1.27.1-2.11

in order to check whether they resolved the problems in this bug report I
commented out the contents of my local.te and did make load in the policy
directory. Bayesian spam filtering and auto-learning as described in comments
#21 to #27 is still not working.

BTW the bug #172088 documents another procmail/spamassassin reicipe using spamc
instead of the old spamassassin command

Just checked with the recently released selinux-policy-targeted-1.27.1-2.14, and
spamd is still not allowed to write to my ~/.spamassassin directory.  Running
with enforce=0 lets things work, but that's a pretty draconian workaround.

Apologies - when used in conjunction with the new kernel (2.6.14-1.1644_FC4smp),
things _do_ work right.  Selinux is enforcing and spamd is happy.