I wonder whether this boolean should really just be "on" by default.
----- Forwarded message from bugzilla@redhat.com -----
From: bugzilla@redhat.com To: jorton@redhat.com Date: Wed, 3 Aug 2005 08:02:27 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164992
Summary: Mod_proxy does not work with SElinux default policy Product: Fedora Core Version: fc4 Platform: i386 OS/Version: Linux Status: NEW Severity: low Priority: normal Component: httpd AssignedTo: jorton@redhat.com ReportedBy: trash_alias@swing.be Estimated Hours: 0.0
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem: Bad: mod_proxy fail if selinux is enabled
[Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(67): proxy: HTTP: canonicalising URL //webmail.XXX.be/exchange/ [Wed Aug 03 13:52:12 2005] [debug] mod_proxy.c(419): Trying to run scheme_handler [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(1062): proxy: HTTP: serving URL https://webmail.XXX.be/exchange/ [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(186): proxy: HTTP connecting https://webmail.XXX.be/exchange/ to webmail.XXX.be:443 [Wed Aug 03 13:52:12 2005] [debug] proxy_util.c(1139): proxy: HTTP: fam 2 socket created to connect to webmail.XXX.be Bad: [Wed Aug 03 13:52:12 2005] [error] (13)Permission denied: proxy: HTTP: attempt to connect to 123.123.123.123:443 (webmail.XXX.be) failed
Version-Release number of selected component (if applicable): selinux-policy-targeted-1.25.3-9 httpd-2.0.54-10.1
How reproducible: Always
Steps to Reproduce: 1.setenforce 1 2.access your http server configured ro reverse proxying 3.fail with message: BAD gateway 4. setenforce 0 5. it work.
Expected Results: I would expect the default policy to allow proxying and Message is not explicit and I had to search a long time to understand....
Additional info:
Joe Orton wrote:
I wonder whether this boolean should really just be "on" by default.
----- Forwarded message from bugzilla@redhat.com -----
From: bugzilla@redhat.com To: jorton@redhat.com Date: Wed, 3 Aug 2005 08:02:27 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164992
Summary: Mod_proxy does not work with SElinux default policy Product: Fedora Core Version: fc4 Platform: i386 OS/Version: Linux Status: NEW Severity: low Priority: normal Component: httpd AssignedTo: jorton@redhat.com ReportedBy: trash_alias@swing.be
Estimated Hours: 0.0
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem: Bad: mod_proxy fail if selinux is enabled
[Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(67): proxy: HTTP: canonicalising URL //webmail.XXX.be/exchange/ [Wed Aug 03 13:52:12 2005] [debug] mod_proxy.c(419): Trying to run scheme_handler [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(1062): proxy: HTTP: serving URL https://webmail.XXX.be/exchange/ [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(186): proxy: HTTP connecting https://webmail.XXX.be/exchange/ to webmail.XXX.be:443 [Wed Aug 03 13:52:12 2005] [debug] proxy_util.c(1139): proxy: HTTP: fam 2 socket created to connect to webmail.XXX.be Bad: [Wed Aug 03 13:52:12 2005] [error] (13)Permission denied: proxy: HTTP: attempt to connect to 123.123.123.123:443 (webmail.XXX.be) failed
Version-Release number of selected component (if applicable): selinux-policy-targeted-1.25.3-9 httpd-2.0.54-10.1
How reproducible: Always
Steps to Reproduce: 1.setenforce 1 2.access your http server configured ro reverse proxying 3.fail with message: BAD gateway 4. setenforce 0 5. it work.
Expected Results: I would expect the default policy to allow proxying and Message is not explicit and I had to search a long time to understand....
Additional info:
We could allow apache to connect to apache ports by default, if that would satisfy this.
On Wed, Aug 03, 2005 at 09:41:43AM -0400, Daniel J Walsh wrote:
Joe Orton wrote:
Expected Results: I would expect the default policy to allow proxying and Message is not explicit and I had to search a long time to understand....
Additional info:
We could allow apache to connect to apache ports by default, if that would satisfy this.
No, when mod_proxy is used as a generic HTTP proxy (a not entirely uncommon configuration) it needs to be able to connect to any remote port on any remote address.
joe
Joe Orton wrote:
On Wed, Aug 03, 2005 at 09:41:43AM -0400, Daniel J Walsh wrote:
Joe Orton wrote:
Expected Results: I would expect the default policy to allow proxying and Message is not explicit and I had to search a long time to understand....
Additional info:
We could allow apache to connect to apache ports by default, if that would satisfy this.
No, when mod_proxy is used as a generic HTTP proxy (a not entirely uncommon configuration) it needs to be able to connect to any remote port on any remote address.
joe
Defaulting apache to can_network_connect_any=1 could allow a subverted apache web server to be setup as a spammer, or a launch site for further attacks. So I don't think this would be a good idea.
On Fri, Aug 05, 2005 at 02:49:37PM -0400, Daniel J Walsh wrote:
Joe Orton wrote:
No, when mod_proxy is used as a generic HTTP proxy (a not entirely uncommon configuration) it needs to be able to connect to any remote port on any remote address.
Defaulting apache to can_network_connect_any=1 could allow a subverted apache web server to be setup as a spammer, or a launch site for further attacks. So I don't think this would be a good idea.
Currently the following is known to be broken in the default configuration:
1) web applications which connect to remote {my,postgre}SQL databases (and similarly, I guess, the Apache SQL-based-authentication modules)
2) all mod_proxy configurations (reverse proxy, forward proxy)
3) the parent connect()-to-listening-port "reap idle children" interface, which has the impact:
a) one log message written to error_log per second when the server acquiesces after a period of above-normal load and tries to reap idle children
b) graceful restart does not work properly
The above all represent important functionality.
I'm not convinced that the security vs usability tradeoff is being won in favour of enabling the boolean by default.
Regards,
joe
On Mon, Aug 08, 2005 at 04:40:42PM +0100, Joe Orton wrote:
On Fri, Aug 05, 2005 at 02:49:37PM -0400, Daniel J Walsh wrote:
Joe Orton wrote:
No, when mod_proxy is used as a generic HTTP proxy (a not entirely uncommon configuration) it needs to be able to connect to any remote port on any remote address.
Defaulting apache to can_network_connect_any=1 could allow a subverted apache web server to be setup as a spammer, or a launch site for further attacks. So I don't think this would be a good idea.
Currently the following is known to be broken in the default configuration:
Another one, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165592
4) web applications which connect to remote LDAP databases, and similarly, I guess, the Apache LDAP-based authentication module, if configured to use remote LDAP databases.
Joe Orton wrote:
On Mon, Aug 08, 2005 at 04:40:42PM +0100, Joe Orton wrote:
On Fri, Aug 05, 2005 at 02:49:37PM -0400, Daniel J Walsh wrote:
Joe Orton wrote:
No, when mod_proxy is used as a generic HTTP proxy (a not entirely uncommon configuration) it needs to be able to connect to any remote port on any remote address.
Defaulting apache to can_network_connect_any=1 could allow a subverted apache web server to be setup as a spammer, or a launch site for further attacks. So I don't think this would be a good idea.
Currently the following is known to be broken in the default configuration:
Another one, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165592
- web applications which connect to remote LDAP databases, and
similarly, I guess, the Apache LDAP-based authentication module, if configured to use remote LDAP databases.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Latest policy has
can_ldap(httpd_t) which should allow httpd scripts to connect to the ldap port. Could I give a similar connect to mysql to solve your problem?
On Mon, Aug 15, 2005 at 11:21:51AM -0400, Daniel J Walsh wrote:
Latest policy has
can_ldap(httpd_t) which should allow httpd scripts to connect to the ldap port. Could I give a similar connect to mysql to solve your problem?
That won't fix (2) or (3), either of which alone would be sufficient justification to enable the boolean by default:
reminder for 2 and 3:
2) all mod_proxy configurations (reverse proxy, forward proxy)
3) the parent connect()-to-listening-port "reap idle children" interface, which has the impact:
joe
Joe Orton wrote:
On Mon, Aug 15, 2005 at 11:21:51AM -0400, Daniel J Walsh wrote:
Latest policy has
can_ldap(httpd_t) which should allow httpd scripts to connect to the ldap port. Could I give a similar connect to mysql to solve your problem?
That won't fix (2) or (3), either of which alone would be sufficient justification to enable the boolean by default:
reminder for 2 and 3:
all mod_proxy configurations (reverse proxy, forward proxy)
the parent connect()-to-listening-port "reap idle children"
interface, which has the impact:
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
How about...
######################################## # Set up networking ########################################
can_network(httpd_t) can_kerberos(httpd_t) can_resolve(httpd_t) can_ypbind(httpd_t) can_ldap(httpd_t) allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; # allow httpd to connect to mysql/posgresql allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; # allow httpd to work as a relay allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t }:tcp_socket name_connect;
On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote:
can_network(httpd_t) can_kerberos(httpd_t) can_resolve(httpd_t) can_ypbind(httpd_t) can_ldap(httpd_t) allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; # allow httpd to connect to mysql/posgresql allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; # allow httpd to work as a relay allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t }:tcp_socket name_connect;
So this would allow connections to ports 80, 8080, etc etc?
Yes, that looks sufficient, but it does seem to defeat the point of having the boolean in the first place :)
joe
Joe Orton wrote:
On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote:
can_network(httpd_t) can_kerberos(httpd_t) can_resolve(httpd_t) can_ypbind(httpd_t) can_ldap(httpd_t) allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; # allow httpd to connect to mysql/posgresql allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; # allow httpd to work as a relay allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t }:tcp_socket name_connect;
So this would allow connections to ports 80, 8080, etc etc?
Yes, that looks sufficient, but it does seem to defeat the point of having the boolean in the first place :)
One example of something that's allowed by setting the boolean but not allowed with the above rules is for httpd_t to connect to an SMTP port. So a compromised httpd can't be used as a spam server.
Paul.
On Tue, Aug 16, 2005 at 12:43:56PM +0100, Paul Howarth wrote:
Joe Orton wrote:
On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote:
can_network(httpd_t) can_kerberos(httpd_t) can_resolve(httpd_t) can_ypbind(httpd_t) can_ldap(httpd_t) allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; # allow httpd to connect to mysql/posgresql allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; # allow httpd to work as a relay allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t }:tcp_socket name_connect;
So this would allow connections to ports 80, 8080, etc etc?
Yes, that looks sufficient, but it does seem to defeat the point of having the boolean in the first place :)
One example of something that's allowed by setting the boolean but not allowed with the above rules is for httpd_t to connect to an SMTP port. So a compromised httpd can't be used as a spam server.
Unless /usr/sbin/sendmail works, which it should.
But I don't think this is the right approach to be taking with this issue.
I think it would be really useful to have a boolean which could be turned on which prevents httpd from making any outgoing TCP connections at all [1]. If I'm running a box with web server and database for your average LAMP webapp, that would be a *really* useful security feature: I can turn it on and significantly mitigate the impact of all PHP issues du jour.
But with this watered down policy, it's not really useful at all. The PHP exploit can go and wget some local kernel exploit code and we're all doomed again.
joe
[1] (note that the *connections to local interfaces* are still needed for the parent-connects-to-port-80 thing even with such a policy enforced)
Joe Orton wrote:
On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote:
can_network(httpd_t) can_kerberos(httpd_t) can_resolve(httpd_t) can_ypbind(httpd_t) can_ldap(httpd_t) allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; # allow httpd to connect to mysql/posgresql allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; # allow httpd to work as a relay allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t }:tcp_socket name_connect;
So this would allow connections to ports 80, 8080, etc etc?
Yes, that looks sufficient, but it does seem to defeat the point of having the boolean in the first place :)
Yes and know, Since the main goal is to stop spamming we have prevented this. I could add another boolean on by default that allowed httpd_relay or something.
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org