Bug 475067 - logrotate and squid
logrotate and squid
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-07 04:09 EST by Ignacio Vazquez-Abrams
Modified: 2009-05-25 07:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-25 07:29:57 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)
another denial, this time failing to read squid.conf in logrotate context (3.05 KB, text/plain)
2009-01-04 17:43 EST, Jon Burgess
no flags Details

  None (edit)
Description Ignacio Vazquez-Abrams 2008-12-07 04:09:14 EST
Summary:

SELinux is preventing sh (logrotate_t) "execute" to ./squid (squid_exec_t).

Detailed Description:

SELinux denied access requested by sh. It is not expected that this access is
required by sh 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 ./squid,

restorecon -v './squid'

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:logrotate_t:s0-s0:c0.c1023
Target Context                system_u:object_r:squid_exec_t:s0
Target Objects                ./squid [ file ]
Source                        sh
Source Path                   /bin/bash
Port                          
Host                          localhost.localdomain
Source RPM Packages           bash-3.2-29.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-26.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18
                              11:58:53 EST 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Sun 07 Dec 2008 04:02:04 AM EST
Last Seen                     Sun 07 Dec 2008 04:02:04 AM EST
Local ID                      5be16d60-55ff-4b59-98ed-1f869f43c52c
Line Numbers                  

Raw Audit Messages            

node=localhost.localdomain type=AVC msg=audit(1228640524.538:1659): avc:  denied  { execute } for  pid=17688 comm="sh" name="squid" dev=dm-0 ino=150758 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:squid_exec_t:s0 tclass=file

node=localhost.localdomain type=SYSCALL msg=audit(1228640524.538:1659): arch=c000003e syscall=21 success=no exit=-13 a0=a59400 a1=1 a2=0 a3=3c08b6da70 items=0 ppid=17687 pid=17688 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=227 comm="sh" exe="/bin/bash" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)




Summary:

SELinux is preventing sh (logrotate_t) "read" to ./squid (squid_exec_t).

Detailed Description:

SELinux denied access requested by sh. It is not expected that this access is
required by sh 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 ./squid,

restorecon -v './squid'

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:logrotate_t:s0-s0:c0.c1023
Target Context                system_u:object_r:squid_exec_t:s0
Target Objects                ./squid [ file ]
Source                        sh
Source Path                   /bin/bash
Port                          
Host                          localhost.localdomain
Source RPM Packages           bash-3.2-29.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-26.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18
                              11:58:53 EST 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Sun 07 Dec 2008 04:02:04 AM EST
Last Seen                     Sun 07 Dec 2008 04:02:04 AM EST
Comment 1 Daniel Walsh 2008-12-08 15:23:35 EST
You can allow this for now.

# audit2allow -M mypol -l -i /var/log/audit/audit.log
# semodule -i mypol.pp

Fixed in selinux-policy-3.5.13-33.fc10
Comment 2 Jon Burgess 2009-01-04 17:43:13 EST
Created attachment 328158 [details]
another denial, this time failing to read squid.conf in logrotate context

I'm seeing a similar denial with selinux-policy-3.5.13-34.fc10.noarch
This time it looks like squid is trying to read its squid.conf file while running in the logrotate security context. 

Running restorecon -v /etc/squid/squid.conf does not report any change.
Comment 3 Daniel Walsh 2009-01-05 13:53:29 EST
Miroslav 


F10 should revert policy back to 

optional_policy(`
	squid_domtrans(logrotate_t)
')
Comment 4 Vadym Chepkov 2009-01-11 08:52:03 EST
As a workaround I added "rotate" function in /etc/rc.d/init.d/squid script, and call it from logrotate instead.
Comment 5 Miroslav Grepl 2009-01-12 09:52:32 EST
Fixed in selinux-policy-3.5.13-39.fc10.noarch
Comment 6 Daniel Walsh 2009-01-12 15:18:24 EST
Vadym, Doesn't /etc/rc.d/init.d/squid reload work?  Or does it need something different?
Comment 7 Vadym Chepkov 2009-01-12 16:23:40 EST
reload executes 'squid -k reconfigure' which causes SIGHUP to be sent.
squid -k rotate sends SIGUSR1. I haven't checked the code, but I assume it's different, otherwise why have two options?
Comment 8 Daniel Walsh 2009-01-13 09:49:04 EST
Ok, sounds reasonable.

Might want to submit a patch to squid package.
Comment 9 Vadym Chepkov 2009-01-18 10:23:09 EST
I still got this AVC

type=AVC msg=audit(1232269357.369:137956): avc:  denied  { read } for  pid=9330 comm="squid" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:squid_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir
Comment 10 Daniel Walsh 2009-01-19 15:17:32 EST
Miroslav add

fs_list_inotify(squid_t)

to F10 policy.



Vadm, 

you can add these rules for now using

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.p
Comment 11 Miroslav Grepl 2009-01-19 15:26:57 EST
Fixed in selinux-policy-3.5.13-40.fc10.noarch
Comment 12 Göran Uddeborg 2009-05-25 05:17:23 EDT
This is working fine for me.  Does that mean I could close this bug, or is that supposed to be done by the reporter?  https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow isn't quite clear, at least not to me.
Comment 13 Daniel Walsh 2009-05-25 07:29:57 EDT
If you verify the bug is fixed, you can close it.

If the Reporter does not agree he can reopen it,  

Thanks for confirming.

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