Re: SELinux does not apply file context to unix domain socket

Christina Plummer <cplummer@xxxxxxxxx> · Mon, 8 Aug 2016 22:50:58 -0400

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@xxxxxxxxxxx> 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

JONIK NSK ---09/08/2016 00:51:02---Hello, I'm trying to configure and run Django application behind Nginx

From:        JONIK NSK <joniknsk@xxxxxxxxx>
To:        selinux@lists.fedoraproject.org
Date:        09/08/2016 00:51
Subject:        SELinux does not apply file context to unix domain socket
Sent by:        eugene.peregudov@xxxxxxxxx

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@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org

--

selinux mailing list

selinux@lists.fedoraproject.org

https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org

--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx