| Summary: | httpd: Permission denied: connect to listener on [::]:80 | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan "Yenya" Kasprzak <kas> | |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> | |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 16 | CC: | awilliam, bughunt, dominick.grift, dwalsh, goeran, hany, jkaluza, jorton, matt_domsch, mgrepl, michael.monreal+bugs, pahan, slishan, yeti | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 812926 (view as bug list) | Environment: | ||
| Last Closed: | 2013-02-14 02:00:45 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 812926 | |||
Yes, we know about this issue and we are trying to find a good solution, since we have now conflicting requirements. But I believe we will need to allow it for now. Can SELinux distinguish between connections to http_port_t on a local adress from connections to remote address? Dummy connection is made to the listening address (0.0.0.0 or [::]), but servers can also listen on a particular local address different to INADDR_ANY. still a problem on f16. Matt any idea how this is going to be implemented with systemd? I think httpd_can_network_connect=on solves it, albeit in a more permissive mode than strictly necessary. Turns out for Wordpress, I need this enabled anyhow. Two birds with one stone. I don't know about systemd here. Presumably systemd listens on the socket at first, hands it to the apache main thread, which hands it to child threads to listen on. httpd_can_network_relay is a much better boolean for this since it ownly opens you up to HTTP ports not all ports. Miroslav Lets experiment in F18 with a label for loopback and see if we can get httpd to connect to port 80 but only on loopback device and not on netif nodes. But if we could get systemd to run the apache command that connects to the real apache service with a different domain, we would not need to do anything. runcon -t initrc_t httpd or apachectl Joe how is this working with systemd? It works exactly the same with systemd as with init scripts, the parent still needs the ability to make connections to IP addresses on any interfaces on which the children may be accepting connections. Ok, so this is still the main httpd_t process connecting to all of its children httpd_t processes on port 80, but not just on localhost? The parent will connect to any one of the addresses to which the listening sockets are bound. By default that is 0.0.0.0:80 / [::]:80 - in a non-default configuration it could be any public IP address, any port. *** Bug 804350 has been marked as a duplicate of this bug. *** Just as a note...I hit something like this after upgrading my server to F17:
Mar 31 18:50:25 webserver kernel: [ 9180.098114] type=1400 audit(1333245025.883:4): avc: denied { name_connect } for pid=5735 comm="httpd" dest=443 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
Mar 31 18:50:59 webserver kernel: [ 9213.239617] type=1400 audit(1333245059.024:5): avc: denied { name_connect } for pid=5732 comm="httpd" dest=443 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
when trying to log in to my Wordpress installation using BrowserID or OpenID (with the browserid and rpx plugins). setsebool -P httpd_can_network_relay on seems to fix it. But I didn't have that issue with F15.
In the browser, I get an error to the effect of 'cannot connect to (some IP address)'.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Adam were they connecting to localhost or to another machine? don't recall. might well be another machine, though, given how browserID and openID work. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. I wonder if there was any resolution of the problem reported here originally... I just ran into this myself on a RHEL 6.5 system (selinux-policy-3.7.19-231.el6.noarch). I tried the workarounds I found here, setting httpd_can_network_relay=on did NOT fix the problem, but httpd_can_network_connect=on did. Now I wonder if this is the correct solution. On Fedora 27: I'm running FosWiki locally, this being just a bunch of perl script called using the good old CGI conventions. Getting that error (I only noticed because I just installed setroubleshoot package). So it has not been fixed... For Fedora 27 see man httpd.service - If using the prefork MPM, the "httpd_graceful_shutdown" SELinux boolean should also be enabled, since with this MPM, httpd needs to establish TCP connections to local ports to successfully complete a graceful restart or shutdown. This boolean can be enabled by running the command: semanage boolean -m --on httpd_graceful_shutdown. |
Description of problem: Apache HTTP server cannot connect to self (see the dummy_connection() function in the httpd source code), so things like graceful reload, honoring the MaxSpareServers option, etc. do not work when in enforcing mode. The error message in Apache error_log is the following one: [Mon Nov 28 16:19:59 2011] [warn] (13)Permission denied: connect to listener on Here is the AVC: type=AVC msg=audit(1322255849.783:29752): avc: denied { name_connect } for pid=7936 comm="httpd" dest=80 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket audit2allow suggests the following booleans: httpd_can_network_relay, allow_ypbind, httpd_can_network_connect I don't think any of them apply, because this is even with pretty minimal Apache configuration (no reverse proxy, no "true" network connections, and definitely no Yellow Pages :-). Adding the following rule fixes the problem: allow httpd_t http_port_t:tcp_socket name_connect; Version-Release number of selected component (if applicable): httpd-2.2.21-1.fc16.x86_64 selinux-policy-3.10.0-56.fc16.noarch selinux-policy-targeted-3.10.0-56.fc16.noarch How reproducible: 100 % Steps to Reproduce: 1. Install Apache httpd, make it listen on [::]:80, start it up. 2. ps ax|grep httpd # list all httpd processes 3. run "service httpd graceful" 4. ps ax|grep httpd Actual results: The master process cannot connect to its children, so the old Apache processes are not terminated and remain running. Expected results: All the previously-existing Apache processes except the master process should terminate, and new ones should be started.