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@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.
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@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Daniel J Walsh wrote:
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
That seems to have worked nicely.
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?
That's looking OK so far too.
Next issue. One of the actions a procmail recipe can have is to forward mail somewhere else. It uses sendmail to do this. Running sendmail from procmail doesn't seem to involve a domain transition, so I get:
Try to read alternatives link for sendmail: Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.428:12692): avc: denied { read } for pid=4316 comm="procmail" name="sendmail" dev=dm-3 ino=131309 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sbin_t:s0 tclass=lnk_file
Try to run sendmail: Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.432:12693): avc: denied { execute } for pid=4316 comm="procmail" name="sendmail.sendmail" dev=dm-3 ino=131306 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.436:12694): avc: denied { execute_no_trans } for pid=4316 comm="procmail" name="sendmail.sendmail" dev=dm-3 ino=131306 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.436:12695): avc: denied { read } for pid=4316 comm="procmail" name="sendmail.sendmail" dev=dm-3 ino=131306 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Sendmail running in procmail_t instead of sendmail_t: Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.548:12696): avc: denied { search } for pid=4316 comm="sendmail" name="clientmqueue" dev=dm-4 ino=1146892 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.548:12697): avc: denied { getattr } for pid=4316 comm="sendmail" name="clientmqueue" dev=dm-4 ino=1146892 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.588:12698): avc: denied { write } for pid=4316 comm="sendmail" name="clientmqueue" dev=dm-4 ino=1146892 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.588:12699): avc: denied { add_name } for pid=4316 comm="sendmail" name="dfk3IHAC7p004316" scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.588:12700): avc: denied { create } for pid=4316 comm="sendmail" name="dfk3IHAC7p004316" scontext=user_u:system_r:procmail_t:s0 tcontext=user_u:object_r:mqueue_spool_t:s0 tclass=file Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.592:12701): avc: denied { lock } for pid=4316 comm="sendmail" name="dfk3IHAC7p004316" dev=dm-4 ino=1149154 scontext=user_u:system_r:procmail_t:s0 tcontext=user_u:object_r:mqueue_spool_t:s0 tclass=file Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.628:12702): avc: denied { name_connect } for pid=4316 comm="sendmail" dest=587 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:smtp_port_t:s0 tclass=tcp_socket Apr 18 18:10:13 goalkeeper kernel: audit(1145380213.008:12703): avc: denied { remove_name } for pid=4316 comm="sendmail" name="dfk3IHAC7p004316" dev=dm-4 ino=1149154 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir Apr 18 18:10:13 goalkeeper kernel: audit(1145380213.008:12704): avc: denied { unlink } for pid=4316 comm="sendmail" name="dfk3IHAC7p004316" dev=dm-4 ino=1149154 scontext=user_u:system_r:procmail_t:s0 tcontext=user_u:object_r:mqueue_spool_t:s0 tclass=file Apr 18 18:10:13 goalkeeper kernel: audit(1145380213.008:12705): avc: denied { read } for pid=4316 comm="sendmail" name="clientmqueue" dev=dm-4 ino=1146892 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir
And finally for today, I have in /etc/procmailrc the following line:
LOGFILE=/var/log/procmail.log
For any account that doesn't override LOGFILE in a per-account .procmailrc, this causes procmail to log message delivery in /var/log/procmail.log. The policy appears to support logging via syslog (something I can't find how to configure), but not to files. Is that right?
Apr 18 17:05:51 goalkeeper kernel: audit(1145376351.930:12668): avc: denied { search } for pid=2774 comm="procmail" name="log" dev=dm-4 ino=851969 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir Apr 18 17:05:51 goalkeeper kernel: audit(1145376351.966:12669): avc: denied { append } for pid=2774 comm="procmail" name="procmail.log" dev=dm-4 ino=852014 scontext=user_u:system_r:procmail_t:s0 tcontext=user_u:object_r:var_log_t:s0 tclass=file
Paul.
Paul Howarth wrote:
One of the actions a procmail recipe can have is to forward mail somewhere else. It uses sendmail to do this. Running sendmail from procmail doesn't seem to involve a domain transition, so I get:
Try to read alternatives link for sendmail: Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.428:12692): avc: denied { read } for pid=4316 comm="procmail" name="sendmail" dev=dm-3 ino=131309 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sbin_t:s0 tclass=lnk_file
Try to run sendmail: Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.432:12693): avc: denied { execute } for pid=4316 comm="procmail" name="sendmail.sendmail" dev=dm-3 ino=131306 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.436:12694): avc: denied { execute_no_trans } for pid=4316 comm="procmail" name="sendmail.sendmail" dev=dm-3 ino=131306 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file Apr 18 18:10:12 goalkeeper kernel: audit(1145380212.436:12695): avc: denied { read } for pid=4316 comm="procmail" name="sendmail.sendmail" dev=dm-3 ino=131306 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
I see from rawhide report that something to address this has gone into selinux-policy-2.2.34-2 (thanks).
Anyway, I tried fixing it myself as follows yesterday:
module procmail 0.1;
require { role object_r; role system_r;
class dir { add_name getattr read remove_name search write }; class file { append create execute execute_no_trans getattr ioctl lock read rename unlink write }; class lnk_file read; class process { noatsecure sigchld siginh transition rlimitinh }; class fd { use }; class fifo_file { getattr read write append ioctl lock };
type procmail_t; type var_log_t; type sbin_t; };
# Needed for writing to /var/log/procmail.log allow procmail_t var_log_t:dir search; allow procmail_t var_log_t:file append;
# Procmail needs to call sendmail for forwarding allow procmail_t sbin_t:lnk_file read; optional_policy(`sendmail',` sendmail_domtrans(procmail_t) ')
This does seem to work but surely there's a tidier way of handling those class requirements? What am I missing?
Paul.
On Fri, 2006-04-21 at 11:02 +0100, Paul Howarth wrote:
Paul Howarth wrote:
module procmail 0.1;
require {
[cut]
class dir { add_name getattr read remove_name search write }; class file { append create execute execute_no_trans getattr ioctl lock read rename unlink write }; class lnk_file read; class process { noatsecure sigchld siginh transition rlimitinh }; class fd { use }; class fifo_file { getattr read write append ioctl lock };
[cut]
This does seem to work but surely there's a tidier way of handling those class requirements? What am I missing?
You want to use the "policy_module(procmail,0.1)" macro instead of the module statement at the top. It adds all of the kernel object classes, so you don't have to write them all out.
Christopher J. PeBenito wrote:
On Fri, 2006-04-21 at 11:02 +0100, Paul Howarth wrote:
Paul Howarth wrote:
module procmail 0.1;
require {
[cut]
class dir { add_name getattr read remove_name search write }; class file { append create execute execute_no_trans getattr ioctl lock read rename unlink write }; class lnk_file read; class process { noatsecure sigchld siginh transition rlimitinh }; class fd { use }; class fifo_file { getattr read write append ioctl lock };
[cut]
This does seem to work but surely there's a tidier way of handling those class requirements? What am I missing?
You want to use the "policy_module(procmail,0.1)" macro instead of the module statement at the top. It adds all of the kernel object classes, so you don't have to write them all out.
Thanks, that's much better:
policy_module(procmail, 0.2)
require { type procmail_t; type sbin_t; type var_log_t; };
# Needed for writing to /var/log/procmail.log allow procmail_t var_log_t:dir search; allow procmail_t var_log_t:file append;
# ============================================== # Procmail needs to call sendmail for forwarding # ============================================== # This should be in selinux-policy-2.2.34-2 onwards
# Read alternatives link allow procmail_t sbin_t:lnk_file read;
# Allow transition to sendmail # (may need similar code for other MTAs that can replace sendmail) optional_policy(`sendmail',` sendmail_domtrans(procmail_t) ')
Cheers, Paul.
Paul Howarth wrote:
Christopher J. PeBenito wrote:
On Fri, 2006-04-21 at 11:02 +0100, Paul Howarth wrote:
Paul Howarth wrote:
module procmail 0.1;
require {
[cut]
class dir { add_name getattr read remove_name search write }; class file { append create execute execute_no_trans getattr
ioctl lock read rename unlink write }; class lnk_file read; class process { noatsecure sigchld siginh transition rlimitinh }; class fd { use }; class fifo_file { getattr read write append ioctl lock };
[cut]
This does seem to work but surely there's a tidier way of handling those class requirements? What am I missing?
You want to use the "policy_module(procmail,0.1)" macro instead of the module statement at the top. It adds all of the kernel object classes, so you don't have to write them all out.
Thanks, that's much better:
policy_module(procmail, 0.2)
require { type procmail_t; type sbin_t; type var_log_t; };
# Needed for writing to /var/log/procmail.log allow procmail_t var_log_t:dir search; allow procmail_t var_log_t:file append;
# ============================================== # Procmail needs to call sendmail for forwarding # ============================================== # This should be in selinux-policy-2.2.34-2 onwards
# Read alternatives link allow procmail_t sbin_t:lnk_file read;
# Allow transition to sendmail # (may need similar code for other MTAs that can replace sendmail) optional_policy(`sendmail',` sendmail_domtrans(procmail_t) ')
selinux-policy-2.2.34-2 has the domain transition allowing procmail to run sendmail, but:
1. it still doesn't allow the sbin_t:lnk_file read to follow the "alternatives" link /usr/sbin/sendmail -> /etc/alternatives/mta
2. there will need to be a transition enabled for other MTAs that can replace sendmail, such as postfix, exim, etc. if their sendmail-compatible command-line program is not labelled sendmail_exec_t.
Paul.
Paul Howarth wrote:
Paul Howarth wrote: selinux-policy-2.2.34-2 has the domain transition allowing procmail to run sendmail, but:
- it still doesn't allow the sbin_t:lnk_file read to follow the
"alternatives" link /usr/sbin/sendmail -> /etc/alternatives/mta
- there will need to be a transition enabled for other MTAs that can
replace sendmail, such as postfix, exim, etc. if their sendmail-compatible command-line program is not labelled sendmail_exec_t.
My latest policy module is:
policy_module(procmail, 0.4.1)
type procmail_tmp_t;
require { type procmail_t; type sbin_t; type var_log_t; };
# Needed for writing to /var/log/procmail.log allow procmail_t var_log_t:dir search; allow procmail_t var_log_t:file append;
# Needed for scripts called from procmail to read/write temp files allow procmail_t procmail_tmp_t:dir create_dir_perms; allow procmail_t procmail_tmp_t:file create_file_perms; files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
# ============================================== # Procmail needs to call sendmail for forwarding # ==============================================
# Read alternatives link (still not in policy) allow procmail_t sbin_t:lnk_file read;
# Allow transition to sendmail # This is in selinux-policy-2.2.34-2 onwards # (may need similar code for other MTAs that can replace sendmail) # optional_policy(`sendmail',` # sendmail_domtrans(procmail_t) # ')
I think I'm nearly there now as the procmail avcs are now few and far between. I just got one I don't understand though:
type=AVC msg=audit(1147796926.268:24816): avc: denied { associate } for pid=27085 comm="bounced-mail" name="bm27083.1" scontext=user_u:object_r:procmail_tmp_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=SYSCALL msg=audit(1147796926.268:24816): arch=40000003 syscall=5 success=yes exit=3 a0=92962d0 a1=8241 a2=1b6 a3=8241 items=1 pid=27085 auid=4294967295 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 comm="bounced-mail" exe="/bin/bash" type=CWD msg=audit(1147796926.268:24816): cwd="/home/mcivta/mail" type=PATH msg=audit(1147796926.268:24816): item=0 name="/tmp/bm27083.1" flags=310 inode=2 dev=fd:02 mode=041777 ouid=0 ogid=0 rdev=00:00
(this is in permissive mode btw)
What's being denied here?
"bounced-mail" is a script I'm using to process mailing list bounces.
Paul.
On Tue, 2006-05-16 at 17:38 +0100, Paul Howarth wrote:
I think I'm nearly there now as the procmail avcs are now few and far between. I just got one I don't understand though:
type=AVC msg=audit(1147796926.268:24816): avc: denied { associate } for pid=27085 comm="bounced-mail" name="bm27083.1" scontext=user_u:object_r:procmail_tmp_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=SYSCALL msg=audit(1147796926.268:24816): arch=40000003 syscall=5 success=yes exit=3 a0=92962d0 a1=8241 a2=1b6 a3=8241 items=1 pid=27085 auid=4294967295 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 comm="bounced-mail" exe="/bin/bash" type=CWD msg=audit(1147796926.268:24816): cwd="/home/mcivta/mail" type=PATH msg=audit(1147796926.268:24816): item=0 name="/tmp/bm27083.1" flags=310 inode=2 dev=fd:02 mode=041777 ouid=0 ogid=0 rdev=00:00
(this is in permissive mode btw)
What's being denied here?
The file type (procmail_tmp_t) hasn't been allowed to be associated with the filesystem type (fs_t). Add: files_type(procmail_tmp_t) to your module source.
selinux@lists.fedoraproject.org