A conflict I mentioned previously (quoted below) between SELinux and 
syslogd over access to utmp has happened to me again, this time on 
another box with a fresh installation of SL4.4 (new installation + yum 
updates).  I don't know what's causing it, but the following seems to 
have fixed it (though I can't rule out side-effects):

[root@staru05 ~]# fixfiles -R initscripts restore
/sbin/restorecon reset context 
/etc/rc.d/rc.sysinit:user_u:object_r:etc_t->system_u:object_r:initrc_exec_t
/sbin/restorecon reset context 
/var/run/utmp:user_u:object_r:var_run_t->system_u:object_r:initrc_var_run_t

So I went back to the first box with this problem -- the only similarity 
there is in the change to /etc/rc.d/rc.sysinit:

[root@ch3linux ~]# fixfiles -R initscripts restore
/sbin/restorecon reset context 
/etc/inittab:user_u:object_r:etc_runtime_t->system_u:object_r:etc_t
/sbin/restorecon reset context 
/etc/rc.d/init.d/networker:root:object_r:etc_t->system_u:object_r:initrc_exec_t
/sbin/restorecon reset context 
/etc/rc.d/rc0.d/K05networker:system_u:object_r:initrc_exec_t->system_u:object_r:etc_t
/sbin/restorecon reset context 
/etc/rc.d/rc.sysinit:user_u:object_r:etc_t->system_u:object_r:initrc_exec_t
/sbin/restorecon reset context 
/etc/rc.d/init.d/networker:system_u:object_r:etc_t->system_u:object_r:initrc_exec_t
/sbin/restorecon reset context 
/etc/rc.d/rc0.d/K05networker:system_u:object_r:initrc_exec_t->system_u:object_r:etc_t

It strikes me as highly unlikely that I'm the only one to encounter 
this...  Or has everyone else decided that SELinux just isn't worth the 
effort and disabled it?  :-(

Fwiw, I have initscripts-7.93.25.EL-1 (i386) on both systems.

-Wayne Betts
Brookhaven National Lab

Wayne Betts wrote:
> Sometime in the last five days, without any system updates or 
> configuration changes that I'm aware of, SELinux on an SL4.4 system 
> has started generating multiple denials per second to syslogd, which 
> in addition to whatever affect it has on syslogd (unknown), it has 
> caused /var/log/messages to grow to 3.5 GB, which logwatch is choking on.
>
> Here are some representative samples of the SELinux log entries:
> Jun 22 15:42:30 ch3linux kernel: audit(1182541346.262:3873423): avc:  
> denied  { read } for  pid=9933 comm="syslogd" name="utmp" dev=dm-0 
> ino=26837003 scontext=user_u:system_r:syslogd_t 
> tcontext=user_u:object_r:var_run_t tclass=file
> Jun 22 15:42:30 ch3linux kernel: audit(1182541346.281:3873424): avc:  
> denied  { read write } for  pid=29535 comm="syslogd" name="utmp" 
> dev=dm-0 ino=26837003 scontext=user_u:system_r:syslogd_t 
> tcontext=user_u:object_r:var_run_t tclass=file
> Jun 22 15:42:30 ch3linux kernel: audit(1182541346.281:3873425): avc:  
> denied  { read } for  pid=29535 comm="syslogd" name="utmp" dev=dm-0 
> ino=26837003 scontext=user_u:system_r:syslogd_t 
> tcontext=user_u:object_r:var_run_t tclass=file
> Jun 22 15:42:30 ch3linux kernel: audit(1182541346.282:3873426): avc:  
> denied  { read write } for  pid=9934 comm="syslogd" name="utmp" 
> dev=dm-0 ino=26837003 scontext=user_u:system_r:syslogd_t 
> tcontext=user_u:object_r:var_run_t tclass=file
> Jun 22 15:42:30 ch3linux kernel: audit(1182541346.282:3873427): avc:  
> denied  { read } for  pid=9934 comm="syslogd" name="utmp" dev=dm-0 
> ino=26837003 scontext=user_u:system_r:syslogd_t 
> tcontext=user_u:object_r:var_run_t tclass=file
>
> Has anyone else seen such a thing?  Any ideas what could be going on?
>
> I've delved only briefly into the mysterious world of SELinux -- I can 
> probably stop this particular denial from happening, but it would be 
> nice to know how this situation arose, and if there is anything 
> serious going on.  I checked a couple other systems for this behaviour 
> and haven't seen it other than this one system.
>
> SELinux, syslogd and utmp are all pretty much core pieces of the Linux 
> puzzle, so I'd hope they would get along naturally without any 
> intervention from me...
>
> -Wayne Betts
> Brookhaven National Lab