Description of problem: Summary: SELinux is preventing squid (squid_t) "read write" to /var/log/cups/access_log-20080316 (cupsd_log_t). Detailed Description: SELinux denied access requested by squid. It is not expected that this access is required by squid and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/log/cups/access_log-20080316, restorecon -v '/var/log/cups/access_log-20080316' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:squid_t:SystemLow-SystemHigh Target Context system_u:object_r:cupsd_log_t Target Objects /var/log/cups/access_log-20080316 [ file ] Source squid Source Path /usr/sbin/squid Port <Unknown> Host hubmaier.ceplovi.cz Source RPM Packages squid-3.0.STABLE1-3.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-17.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name hubmaier.ceplovi.cz Platform Linux hubmaier.ceplovi.cz 2.6.25-0.113.rc5.git2.fc9 #1 SMP Tue Mar 11 22:33:43 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Sun 16 Mar 2008 04:53:46 CET Last Seen Sun 16 Mar 2008 04:53:46 CET Local ID 425c15f8-622e-4dd5-8cac-7b537bdc47c4 Line Numbers Raw Audit Messages host=hubmaier.ceplovi.cz type=AVC msg=audit(1205639626.776:1853): avc: denied { read write } for pid=8949 comm="squid" path="/var/log/cups/access_log-20080316" dev=dm-8 ino=237291 scontext=system_u:system_r:squid_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cupsd_log_t:s0 tclass=file host=hubmaier.ceplovi.cz type=AVC msg=audit(1205639626.776:1853): avc: denied { read write } for pid=8949 comm="squid" path="/var/log/cups/error_log-20080316" dev=dm-8 ino=237382 scontext=system_u:system_r:squid_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cupsd_log_t:s0 tclass=file host=hubmaier.ceplovi.cz type=AVC msg=audit(1205639626.776:1853): avc: denied { read write } for pid=8949 comm="squid" path="/var/log/ejabberd/ejabberd.log-20080316" dev=dm-8 ino=237387 scontext=system_u:system_r:squid_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file host=hubmaier.ceplovi.cz type=AVC msg=audit(1205639626.776:1853): avc: denied { read write } for pid=8949 comm="squid" path="/var/log/ejabberd/sasl.log-20080316" dev=dm-8 ino=237394 scontext=system_u:system_r:squid_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file host=hubmaier.ceplovi.cz type=AVC msg=audit(1205639626.776:1853): avc: denied { read write } for pid=8949 comm="squid" path="/var/log/rpmpkgs-20080316" dev=dm-8 ino=237413 scontext=system_u:system_r:squid_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file host=hubmaier.ceplovi.cz type=AVC msg=audit(1205639626.776:1853): avc: denied { read write } for pid=8949 comm="squid" path="/var/log/setroubleshoot/setroubleshootd.log-20080316" dev=dm-8 ino=237290 scontext=system_u:system_r:squid_t:s0-s0:c0.c1023 tcontext=system_u:object_r:setroubleshoot_var_log_t:s0 tclass=file host=hubmaier.ceplovi.cz type=SYSCALL msg=audit(1205639626.776:1853): arch=c000003e syscall=59 success=yes exit=0 a0=1047280 a1=10472f0 a2=10461e0 a3=320276c9f0 items=0 ppid=8942 pid=8949 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=388 comm="squid" exe="/usr/sbin/squid" subj=system_u:system_r:squid_t:s0-s0:c0.c1023 key=(null) Version-Release number of selected component (if applicable): squid-3.0.STABLE1-3.fc9.x86_64 cups-1.3.6-5.fc9.x86_64 selinux-policy-targeted-3.3.1-17.fc9.noarch
Why should squid need to access that file?
I have no idea what this could be. It looks like a leaked file descriptor or some strange setup. But I no of no relationship between cups and squid.
Created attachment 301630 [details] /etc/squid/squid.conf Well, I don't think it is weird, but this /etc/squid/squid.conf
This looks like squid is checking for read/write access on the files in /var/log? Why don't you think this is weird?
Dan, I think Matej meant that his setup is not weird. I really don't know what could be causing this and Matej told me this only happened once. I can't even imagine this being some bug that would cause squid to try to access these files. Dan, you say that it could be caused by leaked descriptors. Do you have any idea from where they could leak? Matej, do you remember if you were doing something with squid when you received the AVC messages? And, by any chance, is it possible that you have run squid by any other way then by using the service command?
I wonder if logrotate had these files open and then did a service squid restart. That could cause the problem if logrotate was leaking descriptors.
Dan it looks like you're right, this must definitely be it. From squid's logrotate script: /var/log/squid/store.log { [snip] postrotate /usr/sbin/squid -k rotate endscript } CC'ing logrotate's maintainer.
(In reply to comment #5) > And, by any chance, is it possible that you have run squid by any other way > then by using the service command? I am desktop guy, I don't touch these things more than absolutely necessary -- i.e., nothing more than service was every used. At least I don't remember that I would do anything special with it.
No worries Matej, I'm pretty sure now that logrotate is the culprit here.
Cannot reproduce with logrotate -f /etc/logrotate.conf (no SELinux message)
looks like logrotate is potentially leaking file descriptors. Any time logrotate opens a file it should execute fcntl(fd, F_SETFD, FD_CLOEXEC) This will prevent leaked file descriptors and prevent AVC messages like those seen above.
OK. I only would really like to see where exactly does the descriptor leak from... Looking at the squid code, it seems that it scans some directories and since we don't have a reproducer I can't even verify that the blind patch for logrotate would fix the problem.
I don't think a reproducer is needed.. I think it's okay if you close this bug after applying the patch and if someone will have a similar problem again he'll just reopen this bug or creates a new one.
squid does not touch the file descriptors. Before an app is started, the kernel looks at the open file descriptors and the access on those descriptors and checks the new domain, to see if it has access, if the new domain does not have access the kernel will close the file descriptors, and reopen then connected to /dev/null. The kernel will also report the AVC's. Then the kernel will start the application. So if the application never intended to use the file descriptors, the application will work fine.
Bug hunted: one of the open() calls doesn't have a corresponding close() and the descriptors remain opened.
Tomas, could you please backport the fix to F-9? I'm hitting this issue pretty often now. Thanks.
(In reply to comment #16) > Tomas, could you please backport the fix to F-9? I'm hitting this issue pretty > often now. Thanks. It should have been fixed in logrotate-3.7.6-5.fc9. Just update.