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.
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.
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.
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?
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.
Paul.
