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