procmail

[Daniel J Walsh]

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 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.
>
> -- 
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list