Hide Forgot
Description of problem: httpd_can_network_connect_db denied SELinux messages are not logged Running this code from the the command line of the httpd server works as expected, running the same code over httpd in Firefox reports 'connection failed' <?php $connect = pg_connect("host=dbhost dbname=test user=test password=test") or die('connection failed'); return $connect; ?> Setting the bool on the httpd server corrects the connection denied as it should. # setsebool -P httpd_can_network_connect_db 1 The issue in my mind is there was no SELinux denial messages that are logged. How reproducible: Always with SELinux enabled/enforcing These messages are seen in the /var/log/httpd/ssl_error_log at the time of the issue but it gives no indication that there is an issue with the SELinux bool. [Thu May 26 15:38:00 2011] [error] [client XXX.XX.XX.XX] PHP Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied\n\tIs the server running on host "dbhost" and accepting\n\tTCP/IP connections on port 5432? in /var/www/html/website/db_conn.php on line 6, referer: http://XXX.XXX.XXX.XXX/website/ # uname -r 2.6.32-131.0.15.el6.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 (Santiago) selinux-policy-3.7.19-93.el6.noarch php-5.3.3-3.el6.x86_64 php-cli.x86_64 php-pgsql-5.3.3-3.el6.x86_64 httpd-2.2.15-9.el6.x86_64 Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Are you saying you did not see any avc messages in /var/log/audit/audit.log?
Correct, there are no fail avc messages in /var/log/audit/audit.log on the webserver when a connection attempt is made to the remote DB server. Once httpd_can_network_connect_db --> on then the connection will succeed. I can also reproduce this non-logging behavior on a clean local only setup, w/ local DB and local HTTPD. I think logging is working as it should otherwise because when the sebool is toggled from 1 to 0 the event is logged in audit.log which is below. type=MAC_CONFIG_CHANGE msg=audit(1312555411.113:105539): bool=httpd_can_network_connect_db val=1 old_val=0 auid=5076 ses=1 type=SYSCALL msg=audit(1312555411.113:105539): arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=7fff9ab54da0 a2=2 a3=fffffff8 items=0 ppid=19222 pid=22353 auid=5076 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts38 ses=1 comm="setsebool" exe="/usr/sbin/setsebool" subj=unconfined_u:unconfined_r:setsebool_t:s0-s0:c0.c1023 key=(null) type=MAC_CONFIG_CHANGE msg=audit(1312555437.751:105540): bool=httpd_can_network_connect_db val=0 old_val=1 auid=5076 ses=1 type=SYSCALL msg=audit(1312555437.751:105540): arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=7fffbbff2940 a2=2 a3=fffffff8 items=0 ppid=19222 pid=22392 auid=5076 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts38 ses=1 comm="setsebool" exe="/usr/sbin/setsebool" subj=unconfined_u:unconfined_r:setsebool_t:s0-s0:c0.c1023 key=(null)
Could you see what we are dontauditing that is causing the problem. # semodule -DB Will turn off the dontaudit messages Then try your test and see what AVC is generated.
Shouldn't this be closed?
Do the messages show up in the logs when the boolean is turned off now?
Yes, close this case please. I did: 1. semodule -DB 2. setsebool httpd_can_network_connect_db off 3. Attempted HTTP/PHP connection again and fail messages were logged as expected! I knew something was off because I could not replicate this issue on clean RHEL 6.2 test builds, only this production 6.1 box, even an in place update to 6.2 did not resolve the issue. In the future how would I know that rebuilding the policy db would be appropriate? What is the risk. Thanks! audit.log type=MAC_CONFIG_CHANGE msg=audit(1327110044.495:39759): bool=httpd_can_network_connect_db val=0 old_val=1 auid=0 ses=1242 type=SYSCALL msg=audit(1327110044.495:39759): arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=7fffe61552d0 a2=2 a3=fffffff8 items=0 ppid=11724 pid=11759 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1242 comm="setsebool" exe="/usr/sbin/setsebool" subj=unconfined_u:unconfined_r:setsebool_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1327110053.902:39760): avc: denied { name_connect } for pid=5546 comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1327110053.902:39760): arch=c000003e syscall=42 success=no exit=-13 a0=11 a1=7fb3b44ebd10 a2=10 a3=7fff9b5627f4 items=0 ppid=1830 pid=5546 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
Hi Brian, rebuilding policy is not a "fix". In some cases you don't want an AVC denial to appear in the log, e.g. some application has a bug and related AVC denials would be flooding your logs. Therefore you use dontaudit rule to deny the access but don't log this event. What "semodule -DB" does is that it rebuilds your SELinux policy without dontaudit rules and therefore you can see also AVC denials that were "hidden" before. Be aware that removing dontaudit rules results in high amount of AVC denials appearing in your logs. Therefore you don't want to use such a policy for a long time. To rebuild the policy with dontaudit rules again run "semodule -B" (see man semodule). I believe that in your case the reason for dontauditing was that (with boolean disabled) respective AVC denial would be appearing after every browser request (and thus you would get too many AVC denials in your logs). But I may be wrong. > In the future how would I know that rebuilding the policy db would > be appropriate? You might be debugging some problem and your scenario is working in permissive mode (setenforce 0) but failing in enforcing mode when SELinux is effective (seteforce 1) and you don't see any AVC denial. In that case you might want to rebuild selinux policy without dontaudit rules temporarily just to see what selinux is preventing the application to do. Also you might want to read this http://danwalsh.livejournal.com/11673.html
I see, enabling dontaudit again via "semodule -B" did hide the AVC denial again. So yes you are correct, it is not a fix and I do still do have the problem. Thanks for the explanation. This is still only a problem in the sense that when I was originally deploying the application I didn't know why I was having connection failures. I now know how to disable_dontaudit so this is good to help diagnose other issues in the future, but I'm still concerned why this box behaves differently than others. Also, SELinux is in the "Enforcing" state during all of my tests. I don't know what else to try at this point. Thanks for the help.
Hi, your AVC is actually dontaudited in allow_ypbind boolean (see bellow), could you check it's value across your systems? $ sesearch --dontaudit -s httpd_t -t postgresql_port_t -c tcp_socket -p name_connect -C Found 1 semantic av rules: DT dontaudit httpd_t port_type : tcp_socket { name_bind name_connect } ; [ allow_ypbind ]
getsebool allow_ypbind
Daniel, you called it. The issue is the allow_ypbind boolean! My dev systems have allow_ypbind = off ; production have allow_ypbind = on With "allow_ypbind = off" I will see the error for failed connection for httpd_can_network_connect_db and when "allow_ypbind = on" the message will NOT appear. This is the info Karel requested. [root@rushmore ~]# getsebool allow_ypbind allow_ypbind --> on [root@rushmore ~]# sesearch --dontaudit -s httpd_t -t postgresql_port_t -c tcp_socket -p name_connect -C Found 1 semantic av rules: DT dontaudit httpd_t port_type : tcp_socket { name_bind name_connect } ; [ allow_ypbind ] [root@rushmore ~]# setsebool allow_ypbind off ; getsebool allow_ypbind allow_ypbind --> off [root@rushmore ~]# sesearch --dontaudit -s httpd_t -t postgresql_port_t -c tcp_socket -p name_connect -C Found 1 semantic av rules: DT dontaudit httpd_t port_type : tcp_socket { name_bind name_connect } ; [ allow_ypbind ]
I didn't request the info. I just wanted to show you how to find the respective boolean (allow_ypbind) using the sesearch command. :-) Anyway, I am closing this as NOT_A_BUG. Please reopen in case you don't agree.
I'm sorry but I don't agree with the CLOSED status. This to me is such an obscure SELinux case that the average RHCE couldn't figure it out. Forget about how the rules are written for a moment, what does ypbind have to do with httpd and postgress connectivity.
We do not want ypbind binding to named ports, so we setup a dontaudit, so it will eventually bind to a unnamed port. Currently policy basically says. if allow_ypbind dontaudit ALLPROCESSES NAMED_PORTS:tcp_socket { name_bind name_connect } allow ALLPROCESSES UNNAMED_PORT:tcp_socket { name_bind name_connect } fi I guess we can take away the name_connect part of this and see what happens.
Fixed in selinux-policy-3.7.19-138.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0780.html