SCIENTIFIC-LINUX-USERS Archives

June 2007

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wayne Betts <[log in to unmask]>
Reply To:
Wayne Betts <[log in to unmask]>
Date:
Fri, 22 Jun 2007 15:53:40 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
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

ATOM RSS1 RSS2