Paul Howarth wrote:
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
You could relabel it bin_t?
chcon -t bin_t ~/bin/spamdomain
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):
Shouldn't sa-learn be labeled spamc_exec_t?
If you change it to
chcon -t spamc_exec_t /usr/bin/sa-learn
Does it work?
Procmail recipe:
:0c
| sa-learn --username=paul@xxxxxxxxxxxx --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.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
