Bug 690340

Summary: SELinux is preventing sedispatch from 'write' accesses on the sock_file log.
Product: [Fedora] Fedora Reporter: bsfmig <bigslowfat>
Component: selenium-remote-controlAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: dwalsh, lkundrak, mgrepl, shadowbu
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:9a2d09331c2238887957b06e4557ab307447aca14744ac0525818b0c0371c880
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-28 11:35:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description bsfmig 2011-03-24 00:51:32 UTC
SELinux is preventing sedispatch from 'write' accesses on the sock_file log.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that sedispatch should be allowed write access on the log sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sedispatch /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:audisp_t:s0
Target Context                system_u:object_r:device_t:s0
Target Objects                log [ sock_file ]
Source                        sedispatch
Source Path                   sedispatch
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-6.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux localhost.localdomain 2.6.38-1.fc15.x86_64
                              #1 SMP Tue Mar 15 05:29:00 UTC 2011 x86_64 x86_64
Alert Count                   8671
First Seen                    Mon 21 Mar 2011 03:24:06 PM CST
Last Seen                     Thu 24 Mar 2011 08:50:28 AM CST
Local ID                      73f4025e-c491-4102-92fc-7749aba20207

Raw Audit Messages
type=AVC msg=audit(1300927828.461:5840): avc:  denied  { write } for  pid=880 comm="sedispatch" name="log" dev=devtmpfs ino=15716 scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=sock_file


Hash: sedispatch,audisp_t,device_t,sock_file,write

audit2allow

#============= audisp_t ==============
allow audisp_t device_t:sock_file write;

audit2allow -R

#============= audisp_t ==============
allow audisp_t device_t:sock_file write;

Comment 1 bsfmig 2011-03-24 00:54:22 UTC
Meanwhile, setroubleshootd eats up some 70% of CPU usage, resulting a high CPU temperature and loud fan sound.
It also automatically respawns when attempting to terminate it via kill -9.

Comment 2 Miroslav Grepl 2011-03-24 08:55:47 UTC
What context is syslog running as?

# ps -eZ | grep syslog

/dev/log should not be labeled device_t

Did you run syslogd by hand?

Also what does

# ls -lZ /dev/log

# rpm -q systemd

show

Comment 3 Miroslav Grepl 2011-03-24 08:56:09 UTC
*** Bug 690341 has been marked as a duplicate of this bug. ***

Comment 4 bsfmig 2011-03-24 14:15:28 UTC
[root@localhost ~]# ps -eZ | grep syslog
system_u:system_r:syslogd_t:s0    362 ?        00:00:00 systemd-kmsg-sy
system_u:system_r:initrc_t:s0     904 ?        00:00:00 rsyslogd
[root@localhost ~]# ls -lZ /dev/log
srw-rw-rw-. root root system_u:object_r:device_t:s0    /dev/log
[root@localhost ~]# rpm -q systemd
systemd-20-1.fc15.x86_64


What context is syslog running as?
May you give a further explanation on this question?

Did you run syslogd by hand?
[root@localhost ~]# rsyslogd 
 Already running.


Additional info:
Recently I encountered a rsyslog-5.7.9-1 problem (https://bugzilla.redhat.com/show_bug.cgi?id=689163 and https://bugzilla.redhat.com/show_bug.cgi?id=689435) rendering the system unbootable, so I was forced to downgrade it in a chrooted environment in a side-by-side Ubuntu Natty installation.

Comment 5 bsfmig 2011-03-24 14:27:20 UTC
dmesg also tells:
[root@localhost ~]# dmesg|tail
[  494.852460] audispd[867]: queue is full - dropping event
[  494.895282] audispd[867]: queue is full - dropping event
[  494.903583] audispd[867]: queue is full - dropping event
[  494.911869] audispd[867]: queue is full - dropping event
[  495.000980] audispd[867]: queue is full - dropping event
[  495.009283] audispd[867]: queue is full - dropping event
[  495.017617] audispd[867]: queue is full - dropping event
[ 1010.949496] ntpd[763]: 0.0.0.0 c612 02 freq_set kernel 13.999 PPM
[ 1010.949506] ntpd[763]: 0.0.0.0 c615 05 clock_sync
[ 1048.543146] auditd[865]: Audit daemon rotating log files
and ABRT complains about its quota being reached.

Comment 6 Daniel Walsh 2011-03-24 18:40:41 UTC
restorecon /dev/log

Comment 7 bsfmig 2011-03-27 03:10:19 UTC
Please close this bug since I've erased the buggy Fedora 15 and installed a latest daily build from scratch. After that, the issue is gone.