Bug 1632231 - libvirt SELinux policy doesn't allow access to sockets in the home directory
Summary: libvirt SELinux policy doesn't allow access to sockets in the home directory
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.6
Hardware: x86_64
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: mxie@redhat.com
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 1642385
TreeView+ depends on / blocked
Reported: 2018-09-24 12:13 UTC by Richard W.M. Jones
Modified: 2019-04-24 12:29 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1632220
: 1642385 (view as bug list)
Last Closed: 2019-04-24 12:29:28 UTC
Target Upstream Version:

Attachments (Terms of Use)
log (8.98 KB, text/plain)
2018-09-24 13:23 UTC, Richard W.M. Jones
no flags Details
log2 (8.19 KB, text/plain)
2018-09-24 13:25 UTC, Richard W.M. Jones
no flags Details
tps-nbdkit-1.2.6-1.el7.src.rpm-x86_64-rebuild.log (125.74 KB, text/plain)
2018-09-25 10:34 UTC, mxie@redhat.com
no flags Details
tps-selinux.log (18.64 KB, text/plain)
2018-09-25 10:35 UTC, mxie@redhat.com
no flags Details
0001-tests-tls-Use-selinux-label-flag-if-using-SVirt-RHBZ.patch (1.43 KB, text/plain)
2018-09-25 13:13 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2018-09-24 12:13:03 UTC
Rebuilding the nbdkit SRPM at the command line fails:

$ rpmbuild --rebuild nbdkit-1.2.6-1.el7.src.rpm 

In the log we see:

Original error from libvirt: internal error: qemu unexpectedly closed the monitor: 2018-09-24T12:00:30.460741Z qemu-kvm: -drive file=nbd:unix:/home/rjones/rpmbuild/BUILD/nbdkit-1.2.6/tests/cache.sock,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback: Failed to connect socket /home/rjones/rpmbuild/BUILD/nbdkit-1.2.6/tests/cache.sock: Permission denied [code=1 int1=-1]


Original error from libvirt: internal error: qemu unexpectedly closed the monitor: 2018-09-24T12:00:33.340492Z qemu-kvm: -drive file=nbd:unix:/home/rjones/rpmbuild/BUILD/nbdkit-1.2.6/tests/cow.sock,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback: Failed to connect socket /home/rjones/rpmbuild/BUILD/nbdkit-1.2.6/tests/cow.sock: Permission denied [code=1 int1=-1]

The failures comes from the following tests:


There are two associated SELinux failures:

time->Mon Sep 24 13:00:30 2018
type=PROCTITLE msg=audit(1537790430.460:308): proctitle=2F7573722F6C696265786563
type=SYSCALL msg=audit(1537790430.460:308): arch=c000003e syscall=42 success=no 
exit=-13 a0=f a1=7ffee8673670 a2=6e a3=0 items=0 ppid=1 pid=10749 auid=1000 uid=
1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=
(none) ses=1 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=unconfined_u:uncon
fined_r:svirt_t:s0:c209,c276 key=(null)
type=AVC msg=audit(1537790430.460:308): avc:  denied  { write } for  pid=10749 comm="qemu-kvm" name="cache.sock" dev="dm-2" ino=44232564 scontext=unconfined_u:unconfined_r:svirt_t:s0:c209,c276 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=sock_file

time->Mon Sep 24 13:00:33 2018
type=PROCTITLE msg=audit(1537790433.339:310): proctitle=2F7573722F6C6962657865632F71656D752D6B766D002D6E616D650067756573743D677565737466732D6B777030676B307A6E343031797A36772C64656275672D746872656164733D6F6E002D53002D6F626A656374007365637265742C69643D6D61737465724B6579302C666F726D61743D7261772C66696C653D2F686F6D
type=SYSCALL msg=audit(1537790433.339:310): arch=c000003e syscall=42 success=no exit=-13 a0=f a1=7ffe94ae8900 a2=6e a3=0 items=0 ppid=1 pid=10886 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=unconfined_u:unconfined_r:svirt_t:s0:c334,c931 key=(null)
type=AVC msg=audit(1537790433.339:310): avc:  denied  { write } for  pid=10886 comm="qemu-kvm" name="cow.sock" dev="dm-2" ino=44232568 scontext=unconfined_u:unconfined_r:svirt_t:s0:c334,c931 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=sock_file

audit2allow suggests:

#============= svirt_t ==============
allow svirt_t user_home_t:sock_file write;

Comment 3 Richard W.M. Jones 2018-09-24 12:19:08 UTC
Easier reproducer would be something like this, run from your
home directory:

$ nbdkit -U test.sock example1
$ guestfish --ro --format=raw -a nbd://?socket=`pwd`/test.sock run
Original error from libvirt: internal error: qemu unexpectedly closed the monitor: 2018-09-24T12:18:39.258463Z qemu-kvm: -drive file=/tmp/libguestfs1opfEu/overlay1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=unsafe: Could not open backing file: Failed to connect socket /home/rjones/test.sock: Permission denied [code=1 int1=-1]
$ killall nbdkit

Comment 4 Jiri Denemark 2018-09-24 13:04:46 UTC
The socket would have to be labeled with a different context, something like
unconfined_u:unconfined_r:svirt_image_t:s0:c334,c931, however libvirt should
normally take care of labeling it properly. Could you please share the XML
passed to libvirt?

Comment 5 Richard W.M. Jones 2018-09-24 13:23:27 UTC
Created attachment 1486404 [details]

For the XML see the attached log which contains XML + other information.

Comment 6 Richard W.M. Jones 2018-09-24 13:25:40 UTC
Created attachment 1486405 [details]

Actually the socket is only mentioned indirectly since it's in the
backing file of the qcow2 overlay we create.

In the second log (attached) we're opening the socket directly so
it appears in the XML - this also fails.

Comment 7 mxie@redhat.com 2018-09-25 06:19:11 UTC
Hi Richard,

   I note the error info of tps-srpmtest of nbdkit is little different with comment0, could you please confirm if they are same problem?

The error info of rebuild test:

Original error from libvirt: internal error: process exited while connecting to monitor: libvirt:  error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied [code=1 int1=-1]

The error info of selinux test:

#Below part is same with comment0#

time->Mon Sep 24 08:11:49 2018
type=PROCTITLE msg=audit(1537791109.043:2138): proctitle=2F7573722F7362696E2F6C69627669727464002D2D74696D656F75743D3330
type=SYSCALL msg=audit(1537791109.043:2138): arch=c000003e syscall=59 success=no exit=-13 a0=7f03dc00bc00 a1=7f03dc00f620 a2=7f03dc009410 a3=8 items=0 ppid=1 pid=25729 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=system_u:system_r:unconfined_service_t:s0 key=(null)

#But this part is different with comment0#
type=AVC msg=audit(1537791109.043:2138): avc:  denied  { transition } for  pid=25729 comm="libvirtd" path="/usr/libexec/qemu-kvm" dev="sda2" ino=131758 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=system_u:system_r:svirt_tcg_t:s0:c392,c975 tclass=process

Comment 8 Richard W.M. Jones 2018-09-25 09:01:44 UTC
Yes it looks different.  However I don't have the full log from
the TPS test so I don't really know what the problem is there.

Comment 9 mxie@redhat.com 2018-09-25 10:33:33 UTC
Hi, Richard,

    I have attached the related log which are got from TPS test, please check, thanks!

Comment 10 mxie@redhat.com 2018-09-25 10:34:58 UTC
Created attachment 1486707 [details]

Comment 11 mxie@redhat.com 2018-09-25 10:35:38 UTC
Created attachment 1486708 [details]

Comment 12 Richard W.M. Jones 2018-09-25 11:23:31 UTC
Please ignore comments 7-11 as those relate to a different bug.

Comment 13 Jiri Denemark 2018-09-25 11:39:00 UTC
Anyway, looks like while we are relabeling disk images including the whole
backing chain, we don't do so if an nbd unix socket is in the backing chain.

Comment 14 Richard W.M. Jones 2018-09-25 12:14:33 UTC
I wonder if this is related to

Comment 15 Richard W.M. Jones 2018-09-25 13:13:32 UTC
Created attachment 1486741 [details]

I think by far the most frustrating and weird thing about this bug is
that it only affects local rpmbuild.  Even 'rhpkg local' builds are not
affected, and certainly building from the upstream git repo works just

Anyway I had the attached patch.  However I can no longer test
to see if it fixes the problem or not.

Comment 16 Richard W.M. Jones 2019-04-11 08:03:30 UTC
See also bug 1698437 which is similar but slightly different.

Comment 17 Jaroslav Suchanek 2019-04-24 12:29:28 UTC
This bug is going to be addressed in next major release within existing cloned bug.

Note You need to log in before you can comment on or make changes to this bug.