This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 462027 - SELinux prevents squid from acting as an rsync proxy
SELinux prevents squid from acting as an rsync proxy
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-11 22:03 EDT by Ben Webb
Modified: 2008-11-17 17:05 EST (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Ben Webb 2008-09-11 22:03:52 EDT
Description of problem:
I have squid set up on one machine, acting as an rsync proxy - more specifically, I have the following directives in my squid.conf to make it listen on port 873:
acl SSL_ports port 443 563 873
...
acl Safe_ports port 873         # rsync
...
http_port 873

Unfortunately, this doesn't work any more (I'm pretty sure it used to, but I don't use rsync on the client machine too often so can't be sure exactly when it broke). SELinux will not let it bind to port 873 on startup (this is on an x86_64 Fedora 9 system, in enforcing mode):

Sep 11 18:23:17 diva kernel: type=1400 audit(1221182597.789:8): avc:  denied  { name_bind } for  pid=28455 comm="squid" src=873 scontext=unconfined_u:system_r:squid_t:s0 tcontext=system_u:object_r:rsync_port_t:s0 tclass=tcp_socket

If I put the system into permissive mode, it works but reports an avc every time my rsync client connects:

Sep 11 18:23:29 diva kernel: type=1400 audit(1221182609.894:10): avc:  denied  { name_connect } for  pid=28455 comm="squid" dest=873 scontext=unconfined_u:system_r:squid_t:s0 tcontext=system_u:object_r:rsync_port_t:s0 tclass=tcp_socket


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.3.1-84.fc9.noarch
squid-3.0.STABLE7-1.fc9.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Install squid and add the directives above to the config file.
2. "service squid start"
  
Actual results:
squid starts up, but an avc is reported and "netstat -an" shows no process listening on port 873.


Expected results:
squid binds to port 873 and accepts rsync connections.

Additional info:
If blocking port 873 is intentional behavior for SELinux policy, then I'll go ahead and add a custom policy module to allow it on my system (or just switch to permissive mode on the rare occasion that I need that rsync proxy). But I thought I should let you know in case this is *not* intentional, and a genuine bug.
Comment 1 Daniel Walsh 2008-09-18 16:51:25 EDT
 getsebool -a | grep squid
squid_connect_any --> off

You can turn this boolean on or add custom policy.

Or you can convince me that squid should be able to forward rsync packets out of the box.
Comment 2 Ben Webb 2008-09-18 17:52:55 EDT
OK, I turned that on with
setsebool -P squid_connect_any on

I still get
Sep 18 14:46:17 diva kernel: type=1400 audit(1221774377.681:19): avc:  denied  { name_bind } for  pid=15174 comm="squid" src=873 scontext=unconfined_u:system_r:squid_t:s0 tcontext=system_u:object_r:rsync_port_t:s0 tclass=tcp_socket

when I start up squid though, even with an update to selinux-policy-targeted-3.3.1-87.fc9.noarch.

Turning this bool on *does* make the name_connect avc go away though. I'm happy to turn this bool on, but don't really see the point in allowing connects if squid can't bind to the socket in the first place! If there's some reason for this behavior (and it's not a bug), then sure, I can leave the bool off and add custom policy.
Comment 3 Daniel Walsh 2008-10-10 16:49:08 EDT
Fixed in selinux-policy-3.3.1-101.fc9
Comment 4 Daniel Walsh 2008-11-17 17:05:43 EST
Closing all bugs that have been in modified for over a month.  Please reopen if the bug is not actually fixed.

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