Bug 1792713

Summary: libvirtd tries to connect to virtlockd's socket with svirt_t context
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Han Han <hhan>
Component: libvirtAssignee: Daniel Berrangé <berrange>
Status: CLOSED WONTFIX QA Contact: Han Han <hhan>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.2CC: chhu, dyuan, fjin, gruenwald, jdenemar, jsuchane, lmen, lvrabec, mmalik, o.freyermuth, plautrba, ssekidde, wienemann, xuzhang
Target Milestone: rcKeywords: Regression, Triaged
Target Release: 8.2   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-07-19 07:30:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Han Han 2020-01-19 10:31:39 UTC 
Description of problem:
as subject

Version-Release number of selected component (if applicable):
libvirt-6.0.0-1.module+el8.2.0+5453+31b2b136.x86_64
qemu-kvm-4.2.0-6.module+el8.2.0+5453+31b2b136.x86_64
selinux-policy-3.14.3-30.el8.noarch

How reproducible:
100%

Steps to Reproduce:
1. Set qemu.conf:
lock_manager = "lockd"

2. Restart libvirtd and virtlockd
# systemctl restart libvirtd.socket virtlockd.socket libvirtd virtlockd

3. Try to start an VM:
#  virsh start pc                                                       
error: Failed to start domain pc
error: internal error: Process exited prior to exec: libvirt: XML-RPC error : Failed to connect socket to '/run/libvirt/virtlockd-sock': Permission denied 

Permission deni in /var/log/message:
Jan 19 18:22:25 lab setroubleshoot[13140]: SELinux is preventing /usr/sbin/libvirtd from connectto access on the unix_stream_socket /run/libvirt/virtlockd-sock. For complete SELinux messages run: sealert -l 37b77135-dbe2-46ab-8c7d-279f2312cdaa
Jan 19 18:22:25 lab platform-python[13140]: SELinux is preventing /usr/sbin/libvirtd from connectto access on the unix_stream_socket /run/libvirt/virtlockd-sock.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that libvirtd should be allowed connectto access on the virtlockd-sock unix_stream_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'libvirtd' --raw | audit2allow -M my-libvirtd#012# semodule -X 300 -i my-libvirtd.pp#012

Actual results:
As above

Expected results:
No permission deny

Additional info:
Comment 1 Lukas Vrabec 2020-01-19 12:06:05 UTC 
Hi Han, 

Could you please reproduce the issue and then attach output of: 

# ausearch -m AVC -ts boot 

Thanks,
Lukas.
Comment 2 Han Han 2020-01-20 01:33:33 UTC 
(In reply to Lukas Vrabec from comment #1)
> Hi Han, 
> 
> Could you please reproduce the issue and then attach output of: 
> 
> # ausearch -m AVC -ts boot 
> 
> Thanks,
> Lukas.

Sure, here is AVC log when failed to start vm:
< ----
< time->Mon Jan 20 09:31:15 2020
< type=PROCTITLE msg=audit(1579483875.085:7238): proctitle="/usr/sbin/virtlockd"
< type=SYSCALL msg=audit(1579483875.085:7238): arch=c000003e syscall=62 success=yes exit=0 a0=36c8 a1=f a2=559bb35f5660 a3=7f36f7c38772 items=0 ppid=1 pid=12744 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlockd" exe="/usr/sbin/virtlockd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null)
< type=AVC msg=audit(1579483875.085:7238): avc:  denied  { signal } for  pid=12744 comm="virtlockd" scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:svirt_t:s0:c686,c946 tclass=process permissive=1
< type=AVC msg=audit(1579483875.085:7238): avc:  denied  { kill } for  pid=12744 comm="virtlockd" capability=5  scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=capability permissive=1
< ----
< time->Mon Jan 20 09:31:21 2020
< type=PROCTITLE msg=audit(1579483881.404:7249): proctitle=2F7573722F7362696E2F6C69627669727464002D2D74696D656F757400313230
< type=SYSCALL msg=audit(1579483881.404:7249): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7f2825e54ee0 a2=6e a3=7f283da11538 items=0 ppid=25756 pid=25758 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)
< type=AVC msg=audit(1579483881.404:7249): avc:  denied  { connectto } for  pid=25758 comm="libvirtd" path="/run/libvirt/virtlockd-sock" scontext=system_u:system_r:svirt_t:s0:c741,c957 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0
Comment 3 Milos Malik 2020-01-20 08:36:15 UTC 
Following SELinux denial appeared in enforcing mode:
----
type=PROCTITLE msg=audit(01/20/2020 03:27:45.763:538) : proctitle=/usr/sbin/libvirtd 
type=PATH msg=audit(01/20/2020 03:27:45.763:538) : item=0 name=/var/run/libvirt/virtlockd-sock inode=49393 dev=00:18 mode=socket,600 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:virt_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=CWD msg=audit(01/20/2020 03:27:45.763:538) : cwd=/ 
type=SOCKADDR msg=audit(01/20/2020 03:27:45.763:538) : saddr={ saddr_fam=local path=/var/run/libvirt/virtlockd-sock } 
type=SYSCALL msg=audit(01/20/2020 03:27:45.763:538) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x3 a1=0x7f4e49b88ea0 a2=0x6e a3=0x7f4e54078c08 items=1 ppid=1 pid=7461 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(01/20/2020 03:27:45.763:538) : avc:  denied  { connectto } for  pid=7461 comm=libvirtd path=/run/libvirt/virtlockd-sock scontext=system_u:system_r:svirt_t:s0:c33,c85 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0 
----

Following SELinux denial appeared in permissive mode:
----
type=PROCTITLE msg=audit(01/20/2020 03:28:48.775:555) : proctitle=/usr/sbin/libvirtd 
type=PATH msg=audit(01/20/2020 03:28:48.775:555) : item=0 name=/var/run/libvirt/virtlockd-sock inode=49393 dev=00:18 mode=socket,600 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:virt_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=CWD msg=audit(01/20/2020 03:28:48.775:555) : cwd=/ 
type=SOCKADDR msg=audit(01/20/2020 03:28:48.775:555) : saddr={ saddr_fam=local path=/var/run/libvirt/virtlockd-sock } 
type=SYSCALL msg=audit(01/20/2020 03:28:48.775:555) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x3 a1=0x7f4e49b88ea0 a2=0x6e a3=0x21 items=1 ppid=1 pid=7501 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=libvirtd exe=/usr/sbin/libvirtd subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(01/20/2020 03:28:48.775:555) : avc:  denied  { connectto } for  pid=7501 comm=libvirtd path=/run/libvirt/virtlockd-sock scontext=system_u:system_r:svirt_t:s0:c560,c605 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1 
----
Comment 4 Lukas Vrabec 2020-01-20 09:57:29 UTC 
Hi Jiri,

Is safe to allow virtual machine to connect libvirt daemon? 

Thanks,
Lukas.
Comment 5 Jiri Denemark 2020-01-20 14:23:51 UTC 
(In reply to Lukas Vrabec from comment #4)
> Is safe to allow virtual machine to connect libvirt daemon?

Hmm, this could actually be a bug in libvirt as I think libvirtd should not
connect to vitlockd's socket after it already changed its context to svirt_t.
Comment 6 Lukas Vrabec 2020-01-21 08:39:19 UTC 
Jiri, 

Should I clone this BZ to libvirt component? 

Thanks,
Lukas.
Comment 7 Jiri Denemark 2020-01-21 13:41:18 UTC 
I think moving the bug is more appropriate as no policy modification should be
needed when this bug is fixed.
Comment 12 RHEL Program Management 2021-07-19 07:30:39 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 13 Jaroslav Suchanek 2021-11-04 16:08:25 UTC 
*** Bug 2014390 has been marked as a duplicate of this bug. ***