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):
[EMAIL PROTECTED] ~]# 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:
[EMAIL PROTECTED] ~]# 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
[EMAIL PROTECTED] [EMAIL PROTECTED]
Please do not reply off-list
