procmail

[Paul Howarth]

I use procmail as my local delivery agent from sendmail. In FC5 this 
appears to be running as procmail_t.

Procmail offers the ability to pipe mail through programs (filters), and 
I use this facility from time to time. I'm getting quite a lot of 
denials when doing this and wonder what the right approach to fixing 
them is.



Case 1: a locally-written shell script called "spamdomain"

This is in my ~/bin directory and of type user_home_t

Procmail recipe:
SPAMDOMAIN=`spamdomain`

Result:

Apr 11 16:14:29 goalkeeper kernel: audit(1144768469.242:8006): avc: 
denied  { execute } for  pid=16622 comm="procmail" name="spamdomain" 
dev=dm-1 ino=1399071 scontext=system_u:system_r:procmail_t:s0 
tcontext=user_u:object_r:user_home_t:s0 tclass=file

Apr 11 16:14:29 goalkeeper kernel: audit(1144768469.242:8007): avc: 
denied  { execute_no_trans } for  pid=16622 comm="procmail" 
name="spamdomain" dev=dm-1 ino=1399071 
scontext=system_u:system_r:procmail_t:s0 
tcontext=user_u:object_r:user_home_t:s0 tclass=file



Case 2: piping mail through "sa-learn"

I run spamass-milter to reject mail in-protocol and then my own local 
filter using procmail on anything that gets through. If I'm sure 
something's spam, I like spamassassin to learn about it so I might 
reject it earlier in future. So I pipe it through sa-learn (spamd_exec_t):

Procmail recipe:
:0c
| sa-learn --username=paul at city-fan.org --spam >/dev/null 2>&1

Result:

Apr 11 16:14:41 goalkeeper kernel: audit(1144768481.743:8008): avc: 
denied  { getattr } for  pid=16718 comm="bash" name="sa-learn" dev=dm-3 
ino=852750 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:spamd_exec_t:s0 tclass=file

Apr 11 16:14:41 goalkeeper kernel: audit(1144768481.747:8009): avc: 
denied  { execute } for  pid=16718 comm="bash" name="sa-learn" dev=dm-3 
ino=852750 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:spamd_exec_t:s0 tclass=file

Apr 11 16:14:41 goalkeeper kernel: audit(1144768481.747:8010): avc: 
denied  { read } for  pid=16718 comm="bash" name="sa-learn" dev=dm-3 
ino=852750 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:spamd_exec_t:s0 tclass=file

Apr 11 16:14:41 goalkeeper kernel: audit(1144768481.747:8011): avc: 
denied  { execute_no_trans } for  pid=16719 comm="bash" name="sa-learn" 
dev=dm-3 ino=852750 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:spamd_exec_t:s0 tclass=file

Apr 11 16:14:41 goalkeeper kernel: audit(1144768481.799:8012): avc: 
denied  { ioctl } for  pid=16719 comm="sa-learn" name="sa-learn" 
dev=dm-3 ino=852750 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:spamd_exec_t:s0 tclass=file

The "bash" denials will be due to procmail forking a shell to handle the 
redirects.




What *should* I be doing here to fix this? I know I could just add local 
policy to fix the denials, but is there a way to do it that's supported 
by existing policy?

Paul.