Bug 437748 - SELinux is preventing squid (squid_t) "read write" to /var/log/cups/access_log-20080316 (cupsd_log_t).
SELinux is preventing squid (squid_t) "read write" to /var/log/cups/access_lo...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: logrotate (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-17 04:23 EDT by Matěj Cepl
Modified: 2008-06-17 02:19 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-05 05:16:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/squid/squid.conf (1.89 KB, text/plain)
2008-04-08 09:24 EDT, Matěj Cepl
no flags Details

  None (edit)
Description Matěj Cepl 2008-03-17 04:23:00 EDT
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
Comment 1 Tim Waugh 2008-03-17 05:29:19 EDT
Why should squid need to access that file?
Comment 2 Daniel Walsh 2008-03-17 08:48:40 EDT
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.
Comment 3 Matěj Cepl 2008-04-08 09:24:25 EDT
Created attachment 301630 [details]
/etc/squid/squid.conf

Well, I don't think it is weird, but this /etc/squid/squid.conf
Comment 4 Daniel Walsh 2008-04-08 10:36:59 EDT
This looks like squid is checking for read/write access on the files in /var/log?

Why don't you think this is weird?
Comment 5 Martin Nagy 2008-04-08 16:07:19 EDT
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?
Comment 6 Daniel Walsh 2008-04-08 16:30:25 EDT
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.
Comment 7 Martin Nagy 2008-04-09 03:08:37 EDT
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.
Comment 8 Matěj Cepl 2008-04-09 05:31:50 EDT
(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.
Comment 9 Martin Nagy 2008-04-09 06:34:45 EDT
No worries Matej, I'm pretty sure now that logrotate is the culprit here.
Comment 10 Matěj Cepl 2008-04-09 07:27:29 EDT
Cannot reproduce with

logrotate -f /etc/logrotate.conf

(no SELinux message)
Comment 11 Daniel Walsh 2008-04-09 08:04:56 EDT
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.
Comment 12 Tomas Smetana 2008-04-10 05:54:37 EDT
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.
Comment 13 Martin Nagy 2008-04-10 08:09:46 EDT
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.
Comment 14 Daniel Walsh 2008-04-10 11:26:22 EDT
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.
Comment 15 Tomas Smetana 2008-04-11 07:19:55 EDT
Bug hunted: one of the open() calls doesn't have a corresponding close() and the
descriptors remain opened.
Comment 16 Martin Nagy 2008-06-16 09:37:03 EDT
Tomas, could you please backport the fix to F-9? I'm hitting this issue pretty
often now. Thanks.
Comment 17 Tomas Smetana 2008-06-17 02:19:06 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.