postfix, procmail and SELinux - No Go

[Marc Schwartz (via MN)]

On Wed, 2006-05-31 at 15:15 +0100, Paul Howarth wrote:
> Paul Howarth wrote:
> > On Tue, 2006-05-30 at 14:47 -0500, Marc Schwartz (via MN) wrote:
> >> For reference, here is my ~/.procmailrc:
> >>
> >> # Scan for viruses using ClamAV + clamassassin
> >> :0 fw
> >> | /usr/local/bin/clamassassin
> >>
> >> # Scan with SpamAssasin (+ razor, pyzor and dcc)
> >> :0 fw
> >> | /usr/bin/spamc -s 256000

Paul,

First, before I forget, I resolved the Evolution crash issue. While I
still contend that the crashes did not occur whilst I had SELinux fully
disabled, the cause appears to be the presence of bad UTF-8 characters
in the Evo contact list.

A search finally led me to this bug report in RH's Bugzilla:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189955

with a working fix noted in the linked GNOME bug report on the same
issue. So at least directly, this has nothing to do with SELinux...  :-)

> Could you also try adding a recipe for forwarding mail somewhere off 
> your system? I suspect that may also fail with postfix as your MTA, and 
> we might as well fix that whilst we're here.
> 
> Something like this ought to do:
> 
> # Test forwarding
> :0
> * Subject: forwarding test
> ! myaccount at hotmail.com

OK.  Did this. The message was of course bounced back by Postfix. I am
not entirely clear what you need here in terms of feedback. I did not
see anything obvious in the audit.log using grep with 'postfix' or
'procmail', as pretty much all of the returned lines involved
"comm='clamscan'" entries.

Let me know on that.

<SNIP OF AUDIT LOG STUFF>

> Right now, time for the local policy module.
> 
> Set yourself up for making local policy modules:
> 
> # yum install checkpolicy
> # cd /root
> # mkdir selinux.local
> # cd selinux.local
> # chcon -R -t usr_t .
> # ln -s /usr/share/selinux/devel/Makefile .
> 
> Make a local policy module for this issue, in this directory:
> 
> 1. Create a file procmail.te with this content:
> 
> policy_module(procmail, 0.5.0)
> 
> require {
>          type procmail_t;
> };
> 
> # temp files
> type procmail_tmp_t;
> files_tmp_file(procmail_tmp_t)
> 
> # log files
> type procmail_var_log_t;
> logging_log_file(procmail_var_log_t)
> 
> # Write log to /var/log/procmail.log
> allow procmail_t procmail_var_log_t:file create_file_perms;
> allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr };
> logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir })
> 
> # Allow programs called from procmail to read/write temp files and dirs
> allow procmail_t procmail_tmp_t:dir create_dir_perms;
> allow procmail_t procmail_tmp_t:file create_file_perms;
> files_type(procmail_tmp_t)
> files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
> 
> # ==============================================
> # Procmail needs to call sendmail for forwarding
> # ==============================================
> 
> # Read alternatives link (still not in policy)
> corecmd_read_sbin_symlinks(procmail_t)
> 
> # 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)
> # sendmail_domtrans(procmail_t)
> 
> # ==============================================
> # Procmail needs to be able to call clamassassin
> # ==============================================
> clamscan_domtrans(procmail_t)
> 
> 2. Create a file procmail.fc with this content:
> 
> /var/log/procmail\.log  -- 
> gen_context(system_u:object_r:procmail_var_log_t,s0)
> 
> (that's one long line)
> 
> 3. Create an empty procmail.if file:
> 
> # touch procmail.if
> 
> 4. Build the policy module
> 
> # make
> 
> Finally, install your new policy module:
> 
> # semodule -i procmail.pp
> 
> Keep running in permissive mode and test out a few things. You should 
> get significantly fewer denials. Please report back whatever you get.

OK.  I did all of the above successfully. Thanks for the hand holding
here.

Before posting back further feedback from the audit.log to save space,
I am going to work on replying to your other follow up message first.

Then, if I need to make further changes, we can see the outcome of those
and I can post back with more up to date information. This way, we can
keep the number of contributing variables under control... :-)

Thanks again,

Marc