On Tuesday 14 November 2006 13:57, Paul Howarth wrote:
>Gene Heskett wrote:
>> On Tuesday 14 November 2006 06:19, Paul Howarth wrote:
>>> Gene Heskett wrote:
>>>> Greetings;
>>>>
>>>> My logs now contain megabytes of selinux spew. I've disabled it for
>>>> the time being, and have forgotten how one goes about having it
>>>> regenerate its 'this is ok' list, can someone refresh me on that?
>>>
>>> Could you post a few samples of this spew?
>>>
>>> Paul.
>>
>> Sure, its quiet now since I've disabled it, but before I did, I had
>> this on an every 90 second or so basis:
>>
>> ============================================
>> Nov 11 01:54:52 coyote kernel: audit(1163228092.870:182): avc: denied
>> { getattr } for pid=4236 comm="fetchmail" name=".fetchmailrc"
>> dev=dm-0 ino=29032467 scontext=system_u:system_r:fetchmail_t:s0
>> tcontext=root:object_r:user_home_t:s0 tclass=file
>
>Fetchmail reading its configuration file; certainly something that
>should be allowed.
>
>> Nov 11 01:54:54 coyote kernel: audit(1163228094.106:183): avc: denied
>> { ioctl } for pid=5633 comm="sh" name="[22634]" dev=pipefs ino=22634
>> scontext=system_u:system_r:fetchmail_t:s0
>> tcontext=system_u:system_r:fetchmail_t:s0 tclass=fifo_file Nov 11
>> 01:54:54 coyote kernel: audit(1163228094.106:184): avc: denied {
>> search } for pid=5633 comm="sh" name="sbin" dev=dm-0 ino=36864001
>> scontext=system_u:system_r:fetchmail_t:s0
>> tcontext=system_u:object_r:sbin_t:s0 tclass=dir Nov 11 01:54:54 coyote
>> kernel: audit(1163228094.114:185): avc: denied { getattr } for
>> pid=4236 comm="fetchmail" name="[22634]" dev=pipefs ino=22634
>> scontext=system_u:sy
>> stem_r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0
>> tclass=fifo_file
>> Nov 11 01:54:54 coyote kernel: audit(1163228094.114:186): avc: denied
>> { write } for pid=4236 comm="fetchmail" name="[22634]" dev=pipefs
>> ino=22634 scontext=system_u:syst
>> em_r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0
>> tclass=fifo_file
>> Nov 11 01:54:54 coyote kernel: audit(1163228094.114:187): avc: denied
>> { read } for pid=5633 comm="procmail" name="[22634]" dev=pipefs
>> ino=22634 scontext=system_u:system
>> _r:fetchmail_t:s0 tcontext=system_u:system_r:fetchmail_t:s0
>> tclass=fifo_file
>
>These all look to be to do with fetchmail piping stuff into procmail,
>which seems reasonable to do.
>
They should be ok.
>> Nov 11 01:54:54 coyote kernel: audit(1163228094.114:188): avc: denied
>> { read } for pid=5633 comm="procmail" name=".procmailrc" dev=dm-0
>> ino=29032466 scontext=system_u:s
>> ystem_r:fetchmail_t:s0 tcontext=root:object_r:user_home_t:s0
>> tclass=file Nov 11 01:54:54 coyote kernel: audit(1163228094.126:189):
>> avc: denied { getattr } for pid=5639 comm="bash" name="formail"
>> dev=dm-0 ino=6925589 scontext=system_u:system_
>> r:fetchmail_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
>> Nov 11 01:54:54 coyote kernel: audit(1163228094.134:190): avc: denied
>> { search } for pid=5643 comm="spamc" name="mail" dev=dm-0
>> ino=24609414 scontext=system_u:system_r:
>> fetchmail_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
>> Nov 11 02:10:53 coyote ntpd[2917]: synchronized to LOCAL(0), stratum
>> 10 Nov 11 02:19:31 coyote ntpd[2917]: synchronized to 193.11.184.180,
>> stratum 2
>> Nov 11 02:19:35 coyote kernel: audit(1163229575.203:191): avc: denied
>> { execute } for pid=5769 comm="procmail" name="spamc" dev=dm-0
>> ino=6935366 scontext=system_u:syste
>> m_r:fetchmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0
>> tclass=file Nov 11 02:19:35 coyote kernel: audit(1163229575.203:192):
>> avc: denied { execute_no_trans } for pid=5769 comm="procmail"
>> name="spamc" dev=dm-0 ino=6935366 scontext=syste
>> m_u:system_r:fetchmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0
>> tclass=file
>> Nov 11 02:19:35 coyote kernel: audit(1163229575.203:193): avc: denied
>> { read } for pid=5769 comm="procmail" name="spamc" dev=dm-0
>> ino=6935366 scontext=system_u:system_r
>>
>> :fetchmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file
>
>I think these are due to a missing transition from the fetchmail to
>procmail domains; audit2allow will generate the wrong fix for this sort
>of problem.
>
Oh oh?
>> Nov 11 03:01:03 coyote kernel: audit(1163232063.108:194): avc: denied
>> { append } for pid=4236 comm="fetchmail" name="fetchmail.log"
>> dev=dm-0 ino=19170983 scontext=syste
>> m_u:system_r:fetchmail_t:s0 tcontext=root:object_r:var_log_t:s0
>> tclass=file
>
>Hmm, fetchmail can't write its log file in /var/log.
Its running as the user gene. Can I open up the perms on that dir?
OTOH, /var/log/fetchmail.log is indeed being written, here is a snip of
the tail -f on it:
[root@coyote ~]# tail -f /var/log/fetchmail.log
fetchmail: 1 message for vze1zpxd at incoming.verizon.net (7288 octets).
fetchmail: reading message vze1zpxd@xxxxxxxxxxxxxxxxxxxx:1 of 1 (7288
octets) fetchmail: flushed
fetchmail: sleeping at Tue 14 Nov 2006 02:33:25 PM EST
fetchmail: awakened at Tue 14 Nov 2006 02:34:55 PM EST
fetchmail: sleeping at Tue 14 Nov 2006 02:34:59 PM EST
fetchmail: awakened at Tue 14 Nov 2006 02:36:29 PM EST
fetchmail: 2 messages for vze1zpxd at incoming.verizon.net (11520 octets).
fetchmail: reading message vze1zpxd@xxxxxxxxxxxxxxxxxxxx:1 of 2 (6692
octets) fetchmail: flushed
fetchmail: reading message vze1zpxd@xxxxxxxxxxxxxxxxxxxx:2 of 2 (4828
octets) fetchmail: flushed
fetchmail: sleeping at Tue 14 Nov 2006 02:36:41 PM EST
fetchmail: awakened at Tue 14 Nov 2006 02:38:11 PM EST
fetchmail: 2 messages for vze1zpxd at incoming.verizon.net (7605 octets).
fetchmail: reading message vze1zpxd@xxxxxxxxxxxxxxxxxxxx:1 of 2 (3748
octets) fetchmail: flushed
fetchmail: reading message vze1zpxd@xxxxxxxxxxxxxxxxxxxx:2 of 2 (3857
octets) fetchmail: flushed
fetchmail: sleeping at Tue 14 Nov 2006 02:38:24 PM EST
Wall time is 14:38.
>> Nov 11 03:01:04 coyote kernel: audit(1163232064.500:195): avc: denied
>> { read } for pid=5923 comm="fetchmail" name="sh" dev=dm-0
>> ino=33128453 scontext=system_u:system_r:
>> fetchmail_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file
>> Nov 11 03:01:04 coyote kernel: audit(1163232064.504:196): avc: denied
>> { execute } for pid=5923 comm="sh" name="procmail" dev=dm-0
>> ino=6933056 scontext=system_u:system_r
>>
>> :fetchmail_t:s0 tcontext=system_u:object_r:procmail_exec_t:s0
>> : tclass=file
>>
>> Nov 11 03:01:04 coyote kernel: audit(1163232064.504:197): avc: denied
>> { execute_no_trans } for pid=5923 comm="sh" name="procmail" dev=dm-0
>> ino=6933056 scontext=system_u
>>
>> :system_r:fetchmail_t:s0 tcontext=system_u:object_r:procmail_exec_t:s0
>>
>> tclass=file
>> Nov 11 03:01:04 coyote kernel: audit(1163232064.504:198): avc: denied
>> { read } for pid=5923 comm="sh" name="procmail" dev=dm-0 ino=6933056
>> scontext=system_u:system_r:fe
>> tchmail_t:s0 tcontext=system_u:object_r:procmail_exec_t:s0 tclass=file
>> Nov 11 03:01:04 coyote kernel: audit(1163232064.508:199): avc: denied
>> { send_msg } for pid=5927 comm="spamc" saddr=127.0.0.1 src=43491
>> daddr=127.0.0.1 dest=783 netif=lo
>> scontext=system_u:system_r:fetchmail_t:s0
>> tcontext=system_u:object_r:spamd_port_t:s0 tclass=tcp_socket
>> Nov 11 03:01:04 coyote kernel: audit(1163232064.508:200): avc: denied
>> { recv_msg } for pid=5927 comm="spamc" saddr=127.0.0.1 src=783
>> daddr=127.0.0.1 dest=43491 netif=lo
>> scontext=system_u:system_r:fetchmail_t:s0
>> tcontext=system_u:object_r:spamd_port_t:s0 tclass=tcp_socket
>> Nov 11 03:06:06 coyote kernel: audit(1163232366.401:201): avc: denied
>> { create } for pid=5967 comm="procmail"
>
>More of the same.
>
>Can you tell us how you are running fetchmail? From a cron job perhaps?
>And how do you invoke procmail from fetchmail?
Best by including my .fetchmailrc, sanitized.
---------------------------
defaults mda "/usr/bin/procmail -d gene"
set logfile "/var/log/fetchmail.log"
set postmaster "gene"
set no bouncemail
set no spambounce
set daemon 90
poll incoming.verizon.net with proto pop3
user ************* with password ******** is gene
poll pop.gmail.com with proto pop3
user ********* with password ********** is gene
options ssl
poll mail.wdtv.com with proto pop3
user ************ with password *********** is gene
# end of file
And its run from /etc/rc.d/rc.local with these lines:
echo starting fetchmail
su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
Thats all so none of that runs as root while I do most of the time.
>> A newer kernel was installed by yumex last night and I'll reboot to it
>> sometime this morning. Where do I find the proceedure to re-enable it
>> after touching some file in / so it resets things properly?
>
># touch /.autorelabel
>
>Set SELinux to permissive mode, then reboot. Do this when you can afford
>for your machine to be off for a while, as relabelling is not a quick
>process.
So I noticed, so I took a short nap :)
>Paul.
--
Cheers, Gene
