If SELinux allows you to qualify things to both process and user ID, then consider running the WSGI application in daemon mode as a different user to the default of www-data (or whatever platform uses), by using the user/group options to WSGIDaemonProcess. You could then qualify it by the user and only allow that user when running code under context of httpd, to make outgoing connections, rather than any user of httpd.
If that is possible, will be interested to see the SELinux command to enable it that way. Graham > On 13 Jul 2017, at 3:13 AM, ncat <[email protected]> wrote: > > Hello Graham, > > I figured it out! > > You pointed me in the right direction mentioning SELinux. I found the > following SELinux Audit log in the /var/log/audit/audit.log file after > attempting the POST: > > type=AVC msg=audit(1499874877.997:2642): avc: denied { name_connect } for > pid=15007 comm="httpd" dest=22 scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:ssh_port_t:s0 tclass=tcp_socket > > So, SELinux was blocking outbound connectivity for httpd, which is my unique > requirement for this specific application. > > To Fix: > > Check httpd_can_network_connect restrictions for SE Linux: > > $ /usr/sbin/getsebool -a | grep "httpd_can_network_connect " > httpd_can_network_connect --> off > > Change that to on: > > $setsebool -P httpd_can_network_connect on > $/usr/sbin/getsebool -a | grep "httpd_can_network_connect " > httpd_can_network_connect --> on > > I am now permitting httpd for all outbound connectivity, which sounds like a > security hole, so next step is to limit this to only the ports necessary, > that is TBD, but at least I found the culprit. Also, It's an internal > deployment, so the attack surface is minimized. > > > Regards. > > > On Wednesday, July 12, 2017 at 11:06:55 AM UTC-4, ncat wrote: > Hello Graham, > > As I have SSL configured, attached are the logs (apache_logs.txt) from the > /var/log/httpd/ssl_error_log with LogLevel debug and ErrorLog > logs/ssl_error_log configured in ssl.conf. I believe it is complete from the > beginning of a client connecting via GET to the index /, hitting POST to > initiate the script, to the traceback from Python. I tested running Apache > and the WSGIDaemonProcess with my user account, knowing I can run the same > Python script with this account without any issues from the command line > (example: running the web.py application from the cli via python app2.py runs > successfully without exception, or simply putting just the python script > alone in a .py file and running it), however, it continues to fail via > Apache/mod_wsgi. > > Please let me know if there is more I can provide to potentially identify the > issue. > > Thank you. > > > On Tuesday, July 11, 2017 at 6:43:52 PM UTC-4, Graham Dumpleton wrote: > I need to see the full context of the error message, not just the error > message. So the full messages around it, and if being raised from Python the > Python exception type and stack trace. > > There is no reason that INET socket connections should be prohibited unless > somehow SELinux is blocking them, which is probably unlikely. The only time > can think would get permission denied with socket connection was if you were > trying to use UNIX socket connection and Apache user doesn't have access to > the path for the UNIX socket. > > Need to see the full error messages to work out where you are getting this. > > Graham > >> On 12 Jul 2017, at 4:15 AM, ncat <[email protected] <>> wrote: >> >> Hello, >> >> >> I am running the following, with a clean install: >> >> · RHEL 7 >> · Apache 2.4.6 >> · mod_wsgi 4.5.15 >> · Python 2.7.5 >> · web.py 0.37 >> >> I have successfully deployed my web.py application via mod_wsgi and Apache, >> however, I am continuing to fight with an issue when I use the Python >> ‘socket’ module inside of my code. I identified that I am receiving the >> socket.error error code [Errno 13] Permission denied. I tried running >> several scripts with socket itself and paramiko, and they both raise the >> same error. Running another module that would communicate with another >> system inside the app, for example, ‘requests’, works just fine. Running >> the app via the web.py built-in CherryPy server works fine. Running the >> scripts via the Python interpreter works fine. >> >> I am redirecting 80 to 443 in the httpd.conf so the ssl.conf contains the >> VirtualHost configuration. >> >> I’ve set the following in /etc/httpd/conf/httpd.conf: >> >> #Global >> WSGISocketPrefix /var/run/httpd/wsgi >> User apache >> Group apache >> >> I also tried /var/run/wsgi, but the results are the same. >> >> Set the following WSGI directives in the VirtualHost in >> /etc/httpd/conf.d/ssl.conf: >> >> #Inside VirtualHost >> WSGIDaemonProcess example.com <http://example.com/> user=apache group=apache >> processes=2 threads=15 >> WSGIProcessGroup example.com <http://example.com/> >> >> Restarting Apache, I see the following file created in /var/run/httpd/wsgi >> (or /var/run/ previously): >> >> srwx------. 1 apache root 0 Jul 11 18:02 wsgi.6619.0.1.sock >> >> I still receive the [Errno 13] Permission denied when trying to run even a >> simple socket script inside my web.py application. (<server_ip> redacted) >> >> >> >> #simple socket script >> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >> server = (<server_ip>,22) >> s.connect(server) >> s.close() >> >> Please let me know if anyone has any idea as to what may be occurring here. >> >> >> Thanks. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <>. >> To post to this group, send email to [email protected] <>. >> Visit this group at https://groups.google.com/group/modwsgi >> <https://groups.google.com/group/modwsgi>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
