SELinux does not apply file context to unix domain socket

[JONIK NSK]

Hello,

I'm trying to configure and run Django application behind Nginx
reverse-proxy. My system is latest CentOS 7.2, SELinux is in Enforcing
mode, selinux-policy-targeted-3.13.1-60.el7_2.7.noarch.

From audit.log messages I see, that SELinux prevent Nginx daemon access to
socket file:
type=AVC msg=audit(1470659579.411:2693): avc:  denied  { write } for
 pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1"
ino=921257
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=sock_file
type=SYSCALL msg=audit(1470659579.411:2693): arch=c000003e syscall=42
success=no exit=-13 a0=e a1=2513ce8 a2=6e a3=7ffd54ae92f0 items=0
ppid=34376 pid=34378 auid=4294967295 uid=992 gid=989 euid=992 suid=992
fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=4294967295
comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
key=(null)
type=AVC msg=audit(1470659579.597:2694): avc:  denied  { write } for
 pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1"
ino=921257
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=sock_file

Socket file is owned by Gunicorn user and has context usr_t, inherited from
/opt/.* rule:
srwxrwxrwx. netbox nginx system_u:object_r:usr_t:s0
/opt/netbox/netbox/netbox/gunicorn.sock

From output of
# sesearch -A -s httpd_t | grep sock_file
I found rule that allows nginx (httpd_t) access to sock_file with
httpd_var_run_t context:
allow httpd_t httpd_var_run_t : sock_file { ioctl read write create getattr
setattr lock append unlink link rename open } ;

Next, I add that file context for my socket file location with s-filetype:
# semanage fcontext -a -f s -t httpd_var_run_t
'/opt/netbox/netbox/netbox/gunicorn\.sock'

Removing and recreating socket file did not solve my problem - file still
has a context usr_t :(
Gunicorn started by systemd and has
context system_u:system_r:unconfined_service_t:s0

Furthermore, restorecon -v /opt/netbox/netbox/netbox/gunicorn.sock does not
effect to applying httpd_var_run_t context to existing file!

I'm confused - I make something wrong or there is a bug in SELinux labeling?

Thanks for replies!

[Philip Seeley]

Hi,

The restorecon should work, so can you just check that the value
in /etc/selinux/targeted/contexts/files/file_contexts.local is as you
expect:

/opt/netbox/netbox/netbox/gunicorn\.sock -s
system_u:object_r:httpd_var_run_t:s0

I note that netbox appears three times in the path. Is this actually
correct?

Once the restorecon works then you might have an issue if the daemon
recreates the socket file and therefore it inherits its parent dir context.
If the socket file is the only thing in this directory you could try
labelling that as httpd_var_run_t too.

Phil




From:	JONIK NSK <joniknsk(a)gmail.com&gt;
To:	selinux(a)lists.fedoraproject.org
Date:	09/08/2016 00:51
Subject:	SELinux does not apply file context to unix domain socket
Sent by:	eugene.peregudov(a)gmail.com



Hello,

I'm trying to configure and run Django application behind Nginx
reverse-proxy. My system is latest CentOS 7.2, SELinux is in Enforcing
mode, selinux-policy-targeted-3.13.1-60.el7_2.7.noarch.

From audit.log messages I see, that SELinux prevent Nginx daemon access to
socket file:
type=AVC msg=audit(1470659579.411:2693): avc:  denied  { write } for
pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1"
ino=921257
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=sock_file
type=SYSCALL msg=audit(1470659579.411:2693): arch=c000003e syscall=42
success=no exit=-13 a0=e a1=2513ce8 a2=6e a3=7ffd54ae92f0 items=0
ppid=34376 pid=34378 auid=4294967295 uid=992 gid=989 euid=992 suid=992
fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=4294967295
comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
key=
(null)
type=AVC msg=audit(1470659579.597:2694): avc:  denied  { write } for
pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1"
ino=921257
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=sock_file

Socket file is owned by Gunicorn user and has context usr_t, inherited
from /opt/.* rule:
srwxrwxrwx. netbox nginx system_u:object_r:usr_t:s0
/opt/netbox/netbox/netbox/gunicorn.sock

From output of
# sesearch -A -s httpd_t | grep sock_file
I found rule that allows nginx (httpd_t) access to sock_file with
httpd_var_run_t context:
allow httpd_t httpd_var_run_t : sock_file { ioctl read write create getattr
setattr lock append unlink link rename open } ;

Next, I add that file context for my socket file location with s-filetype:
# semanage fcontext -a -f s -t httpd_var_run_t
'/opt/netbox/netbox/netbox/gunicorn\.sock'

Removing and recreating socket file did not solve my problem - file still
has a context usr_t :(
Gunicorn started by systemd and has
context system_u:system_r:unconfined_service_t:s0

Furthermore, restorecon -v /opt/netbox/netbox/netbox/gunicorn.sock does not
effect to applying httpd_var_run_t context to existing file!

I'm confused - I make something wrong or there is a bug in SELinux
labeling?

Thanks for replies!

--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/[e-mail]

[Christina Plummer]

Hi!

I actually ran into this one recently as well, on a RHEL7 system. I opened
a case with Red Hat, and while I didn't get a complete answer, it does
appear that the file context of the socket file is somewhat irrelevant. As
best I can tell, the socket actually gets its context from the process that
created it - in my case, the target context in the AVC audit message was
appearing as "init_t", despite the file context (according to ls -lZ)
showing as "var_lib_t". When I checked the context of the process that was
creating the socket (using ps -Z), I saw indeed that it was "init_t".

While it does kind of make sense, it is also confusing - why does ls -lZ
show the context as if it were a regular file, even though it is "actually"
inherited from the listening process? I'd be happy to have someone explain
better to me.

Christina

On Mon, Aug 8, 2016 at 8:17 PM, Philip Seeley <pseeley(a)au1.ibm.com&gt; wrote:

>  Hi,
>
>  The restorecon should work, so can you just check that the value in
>  /etc/selinux/targeted/contexts/files/file_contexts.local is as you expect:
>
>  /opt/netbox/netbox/netbox/gunicorn\.sock -s system_u:object_r:httpd_var_
>  run_t:s0
>
>  I note that netbox appears three times in the path. Is this actually
>  correct?
>
>  Once the restorecon works then you might have an issue if the daemon
>  recreates the socket file and therefore it inherits its parent dir context.
>  If the socket file is the only thing in this directory you could try
>  labelling that as httpd_var_run_t too.
>
>  Phil
>
>
>  [image: Inactive hide details for JONIK NSK ---09/08/2016
>  00:51:02---Hello, I'm trying to configure and run Django application behind
>  N]JONIK NSK ---09/08/2016 00:51:02---Hello, I'm trying to configure and
>  run Django application behind Nginx
>
>  From: JONIK NSK <joniknsk(a)gmail.com&gt;
>  To: selinux(a)lists.fedoraproject.org
>  Date: 09/08/2016 00:51
>  Subject: SELinux does not apply file context to unix domain socket
>  Sent by: eugene.peregudov(a)gmail.com
>  ------------------------------
>
>
>
>  Hello,
>
>  I'm trying to configure and run Django application behind Nginx
>  reverse-proxy. My system is latest CentOS 7.2, SELinux is in Enforcing
>  mode, selinux-policy-targeted-3.13.1-60.el7_2.7.noarch.
>
>  From audit.log messages I see, that SELinux prevent Nginx daemon access to
>  socket file:
>  type=AVC msg=audit(1470659579.411:2693): avc:  denied  { write } for
>   pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1"
> ino=921257
>  scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0
>  tclass=sock_file
>  type=SYSCALL msg=audit(1470659579.411:2693): arch=c000003e syscall=42
>  success=no exit=-13 a0=e a1=2513ce8 a2=6e a3=7ffd54ae92f0 items=0
>  ppid=34376 pid=34378 auid=4294967295 uid=992 gid=989 euid=992 suid=992
>  fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=4294967295
>  comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
>  key=(null)
>  type=AVC msg=audit(1470659579.597:2694): avc:  denied  { write } for
>   pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1"
> ino=921257
>  scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0
>  tclass=sock_file
>
>  Socket file is owned by Gunicorn user and has context usr_t, inherited
>  from /opt/.* rule:
>  srwxrwxrwx. netbox nginx system_u:object_r:usr_t:s0
>  /opt/netbox/netbox/netbox/gunicorn.sock
>
>  From output of
>  # sesearch -A -s httpd_t | grep sock_file
>  I found rule that allows nginx (httpd_t) access to sock_file with
>  httpd_var_run_t context:
>  allow httpd_t httpd_var_run_t : sock_file { ioctl read write create
>  getattr setattr lock append unlink link rename open } ;
>
>  Next, I add that file context for my socket file location with s-filetype:
>  # semanage fcontext -a -f s -t httpd_var_run_t '/opt/netbox/netbox/netbox/
>  gunicorn\.sock'
>
>  Removing and recreating socket file did not solve my problem - file still
>  has a context usr_t :(
>  Gunicorn started by systemd and has context system_u:system_r:
>  unconfined_service_t:s0
>
>  Furthermore, restorecon -v /opt/netbox/netbox/netbox/gunicorn.sock does
>  not effect to applying httpd_var_run_t context to existing file!
>
>  I'm confused - I make something wrong or there is a bug in SELinux
>  labeling?
>
>  Thanks for replies!
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/selinux@lists.
>  fedoraproject.org
>
>
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/selinux@lists.
>  fedoraproject.org
>