Hello Graham,
Great idea, and I like following the principle of least privilege, however,
I do not know if you can get more granular with the SELinux policy then
what I put in place. I'll let you know if I identify a way.
In summary,
*Possible Least Privilege Policy for SELinux httpd Outbound Network
Connectivity*
- process: httpd
- user: <mod_wsgi_user> defined in daemon mode
- Limit TCP outbound Port(s)
- Limit outbound IP Address(es)
Regards.
On Wednesday, July 12, 2017 at 8:27:59 PM UTC-4, Graham Dumpleton wrote:
>
> 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 <nic...@gmail.com <javascript:>> 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 <nic...@gmail.com> 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 user=apache group=apache processes=2
>>> threads=15
>>>
>>> WSGIProcessGroup 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 modwsgi+u...@googlegroups.com.
>>> To post to this group, send email to mod...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/modwsgi.
>>> For more options, visit 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 modwsgi+u...@googlegroups.com <javascript:>.
> To post to this group, send email to mod...@googlegroups.com <javascript:>
> .
> Visit this group at https://groups.google.com/group/modwsgi.
> For more options, visit 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 modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
