Bug 1386970

Ryan, can you take a quick look at this?

Lon/Ryan,

Can one of you look at this?

type=AVC msg=audit(1476895037.121:1403): avc:  denied  { create } for  pid=116361 comm="qemu-kvm" name="vhost2" scontext=system_u:system_r:svirt_t:s0:c45,c690 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file

I only see this AVC.  Maybe an issue in base policy?

I'm assuming this is rhel 7.3?

Can you also re-run in permissive and capture the audit.log immediately after successfully completely?

Yes, this is with 7.3.
The tarball has audit logs for both with selinux in permissive and enforcing mode

OK, so the problem here is specific to creation and use of the socket used for the vhost-user interface.

Do we know the directory in which this socket is being created?

Basically, the context of the directory needs to be something svirt can write to, so we'd need to make the contexts line up.

The sockets are created in the directory: /run/vhost/

# ll /run/ | grep vhost
drwxrwxr-x  2 root kvm         120 Feb 23 22:40 vhost/

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html

The issue is where things are being created. /run/vhost (/var/run/vhost) does not have a default label, so it inherits the parent directory's label.  I believe the label required here is qemu_var_run_t; audit2why seems to believe this will work for svirt writing out files.

So, I am pretty sure that you'll have to do:

# semanage fcontext -a -t qemu_var_run_t "/var/run/vhost(/.*)?"
# restorecon -Rv /var/run/vhost


On my system, qemu_var_run_t files are typically owned by qemu/qemu, so you may also want to do:

# chown -R qemu.qemu /var/run/vhost

On your directory setup seems to want to use root/kvm, with mode 775 on the directory instead of 755, so you'll want to adjust for that.


Start:

[root@localhost ~]# ls -ldZ /run/vhost
ls: cannot access '/run/vhost': No such file or directory
[root@localhost ~]# mkdir /run/vhost
[root@localhost ~]# ls -ldZ /run/vhost
drwxr-xr-x. 2 root root unconfined_u:object_r:var_run_t:s0 40 Mar 10 09:42 /run/vhost
[root@localhost ~]# restorecon /run/vhost
[root@localhost ~]# ls -ldZ /run/vhost
drwxr-xr-x. 2 root root unconfined_u:object_r:var_run_t:s0 40 Mar 10 09:42 /run/vhost

^ Not a useful label.

[root@localhost ~]# touch /run/vhost/foo
[root@localhost ~]# ls -ldZ /run/vhost/foo
-rw-r--r--. 1 root root unconfined_u:object_r:var_run_t:s0 0 Mar 10 09:43 /run/vhost/foo

^ No useful label here, either. Let's try that again

[root@localhost ~]# rm -rf /run/vhost
[root@localhost ~]# semanage fcontext -a -t qemu_var_run_t "/var/run/vhost(/.*)?"

^ Label set

[root@localhost ~]# restorecon /run/vhost
[root@localhost ~]# ls -ldZ /run/vhost
drwxr-xr-x. 2 root root unconfined_u:object_r:qemu_var_run_t:s0 60 Mar 10 09:43 /run/vhost

^ Label active

[root@localhost ~]# touch /run/vhost/foo
[root@localhost ~]# ls -ldZ /run/vhost/foo
-rw-r--r--. 1 root root unconfined_u:object_r:qemu_var_run_t:s0 0 Mar 10 10:01 /run/vhost/foo

^ Possibly wrong permissions; may be installation dependent. Do your own chown -R at this point...

Here's what audit2why has to say about using var_run_t vs. qemu_var_run_t:

type=AVC msg=audit(1476895037.121:1403): avc:  denied  { create } for  pid=116361 comm="qemu-kvm" name="vhost2" scontext=system_u:system_r:svirt_t:s0:c45,c690 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file

	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1476895037.121:1403): avc:  denied  { create } for  pid=116361 comm="qemu-kvm" name="vhost2" scontext=system_u:system_r:svirt_t:s0:c45,c690 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=sock_file

	Was caused by:
		Unknown - would be allowed by active policy
		Possible mismatch between this policy and the one under which the audit message was generated.

		Possible mismatch between current in-memory boolean settings vs. permanent ones.

Thank you Lon for the details above. Very helpful! We shall try out the above and update the BZ.