How to allow nginx communicate with python application over socket?

[Yuri Kanivetsky]

Hi,

I'm trying to make nginx talk to an app over socket. Actually, I seem
to have succeeded, but I'm concerned if the policy I installed is a
good one.

Here's what I see in audit.log when nginx tries to connect to my app:


type=AVC msg=audit(1473789962.311:2330): avc:  denied  { write } for
pid=16814 comm="nginx" name="a1.sock" dev="dm-0" ino=525810
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1473789962.311:2330): arch=c000003e syscall=42
success=no exit=-13 a0=d a1=188a730 a2=6e a3=7ffde6992400 items=0
ppid=16813 pid=16814 auid=4294967295 uid=995 gid=993 euid=995 suid=995
fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295
comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
key=(null)


And here's what audit2allow has generated:


module nginx 1.0;

require {
        type httpd_t;
        type httpd_sys_content_t;
        class sock_file write;
}

#============= httpd_t ==============
allow httpd_t httpd_sys_content_t:sock_file write;


The question is, "Is httpd_sys_content_t an appropriate type for the
task?" Is there the one, that suits better? Or should I create a
separate one?

Regards,
Yuri

[Jeremy Young]

If your nginx is running as httpd_t putting the socket you're connecting to
in /var/run/httpd or /var/run/nginx are two good places to start:

grep httpd_var_run_t /etc/selinux/targeted/contexts/files/file_contexts
/var/run/wsgi.* -s system_u:object_r:httpd_var_run_t:s0
/var/run/mod_.* system_u:object_r:httpd_var_run_t:s0
*/var/run/httpd.* system_u:object_r:httpd_var_run_t:s0*
*/var/run/nginx.* system_u:object_r:httpd_var_run_t:s0*
/var/run/apache.* system_u:object_r:httpd_var_run_t:s0
/var/run/php-fpm(/.*)? system_u:object_r:httpd_var_run_t:s0
/var/run/lighttpd(/.*)? system_u:object_r:httpd_var_run_t:s0
/var/lib/php/session(/.*)? system_u:object_r:httpd_var_run_t:s0
/var/lib/php/wsdlcache(/.*)? system_u:object_r:httpd_var_run_t:s0
/var/run/dirsrv/admin-serv.* system_u:object_r:httpd_var_run_t:s0
/var/opt/rh/rh-nginx18/run/nginx(/.*)? system_u:object_r:httpd_var_run_t:s0
/var/www/openshift/broker/httpd/run(/.*)?
system_u:object_r:httpd_var_run_t:s0
/var/www/openshift/console/httpd/run(/.*)?
system_u:object_r:httpd_var_run_t:s0
/opt/dirsrv/var/run/dirsrv/dsgw/cookies(/.*)?
system_u:object_r:httpd_var_run_t:s0
/var/run/thttpd\.pid -- system_u:object_r:httpd_var_run_t:s0
/var/run/gcache_port -s system_u:object_r:httpd_var_run_t:s0
/var/run/cherokee\.pid -- system_u:object_r:httpd_var_run_t:s0


sesearch -A -C -s httpd_t -c sock_file -p write | grep httpd_var_run_t
   allow httpd_t httpd_var_run_t : sock_file { ioctl read write create
getattr setattr lock append unlink link rename open } ;



On Tue, Sep 13, 2016 at 1:35 PM Yuri Kanivetsky <yuri.kanivetsky(a)gmail.com&gt;
wrote:

>  Hi,
>
>  I'm trying to make nginx talk to an app over socket. Actually, I seem
>  to have succeeded, but I'm concerned if the policy I installed is a
>  good one.
>
>  Here's what I see in audit.log when nginx tries to connect to my app:
>
>
>  type=AVC msg=audit(1473789962.311:2330): avc:  denied  { write } for
>  pid=16814 comm="nginx" name="a1.sock" dev="dm-0"
> ino=525810
>  scontext=system_u:system_r:httpd_t:s0
>  tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=sock_file
>  type=SYSCALL msg=audit(1473789962.311:2330): arch=c000003e syscall=42
>  success=no exit=-13 a0=d a1=188a730 a2=6e a3=7ffde6992400 items=0
>  ppid=16813 pid=16814 auid=4294967295 uid=995 gid=993 euid=995 suid=995
>  fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295
>  comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
>  key=(null)
>
>
>  And here's what audit2allow has generated:
>
>
>  module nginx 1.0;
>
>  require {
>          type httpd_t;
>          type httpd_sys_content_t;
>          class sock_file write;
>  }
>
>  #============= httpd_t ==============
>  allow httpd_t httpd_sys_content_t:sock_file write;
>
>
>  The question is, "Is httpd_sys_content_t an appropriate type for the
>  task?" Is there the one, that suits better? Or should I create a
>  separate one?
>
>  Regards,
>  Yuri
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/[e-mail] 
-- 
Jeremy Young

[Yuri Kanivetsky]

Hi,

Interesting point you've got there. It didn't occur to me. Probably,
because lately I saw a lot of ruby apps (sites), storing sockets and
pids right in their own directories. And after posting my question I
was able to make it work by changing type of the directory, where
socket resides, to httpd_var_run_t.

And now that I think about it, in terms of effort (say, number of
commands) both solutions are identical. One thing that slightly
concerns me in your solution is that the directory looks like the
place for files, owned by packages. Well, maybe because I didn't see
anything other than that there. But lately I see this trend (not sure
how widespread it is, probably has to do with emergence of devops
thing), where apps (sites) run daemons, not backed by init
scripts/service files. Keeping the app in the user's directory, and so
on. And following it, storing pids/sockets in the app directory seems
like a good idea.

But if you think about it, there's probably not much difference.
Anyways, thanks for the idea.

Regards,
Yuri