Wayne Betts wrote:
> 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...

My three nahant-clones (none is sl) are all enforcing and fine.

My one Boron is ok.

-- 

Cheers
John

-- spambait
[log in to unmask]  [log in to unmask]

Please do not reply off-list