7:11 a.m.
I wonder whether this boolean should really just be "on" by default.
----- Forwarded message from bugzilla(a)redhat.com -----
From: bugzilla(a)redhat.com
To: jorton(a)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(a)redhat.com
ReportedBy: trash_alias(a)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:
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
----- End forwarded message -----
8:41 a.m.
Joe Orton wrote:
I wonder whether this boolean should really just be "on" by
default.
----- Forwarded message from bugzilla(a)redhat.com -----
From: bugzilla(a)redhat.com
To: jorton(a)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(a)redhat.com
ReportedBy: trash_alias(a)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.
--
8:45 a.m.
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
1:49 p.m.
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.
--
10:40 a.m.
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
3:21 p.m.
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.
10:21 a.m.
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
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.
--
fedora-selinux-list mailing list
fedora-selinux-list(a)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?
--
10:28 a.m.
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
10:59 a.m.
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:
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
--
fedora-selinux-list mailing list
fedora-selinux-list(a)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;
--
6:39 a.m.
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
6:43 a.m.
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.
7:13 a.m.
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)
12:29 p.m.
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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
6828
days inactive
6841
days old
selinux@lists.fedoraproject.org
12 comments
3 participants
participants (3)
-
Daniel J Walsh -
Joe Orton -
Paul Howarth