Description of problem: I've been using libguestfs + SELinux enforcing for days and everything has been working fine. But suddenly -- and it's unclear how this started -- everything stops working: libguestfs: error: could not create appliance through libvirt: internal error: process exited while connecting to monitor: qemu-system-ppc64: -chardev socket,id=charserial0,path=/home/rjones/d/libguestfs/tmp/libguestfsNoLPoG/console.sock: Failed to connect to socket: Permission denied qemu-system-ppc64: -chardev socket,id=charserial0,path=/home/rjones/d/libguestfs/tmp/libguestfsNoLPoG/console.sock: chardev: opening backend "socket" failed [code=1 domain=10] After setting selinux to Permissive it runs. These are the denials in the logs: ---- time->Thu Sep 12 09:59:44 2013 type=SYSCALL msg=audit(1378976384.018:1122): arch=80000015 syscall=102 success=no exit=-13 a0=3 a1=3fffe5b81060 a2=6e a3=6f6e736f6c652e73 items=0 ppid=1 pid=2130 auid=1000 uid=1000 gid=1001 euid=1000 suid=1000 fsuid=1000 egid=1001 sgid=1001 fsgid=1001 ses=45 tty=(none) comm="qemu-system-ppc" exe="/home/rjones/d/qemu/ppc64-softmmu/qemu-system-ppc64" subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1378976384.018:1122): avc: denied { connectto } for pid=2130 comm="qemu-system-ppc" path="/home/rjones/d/libguestfs/tmp/libguestfsQ7RQR7/console.sock" scontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket ---- time->Thu Sep 12 10:00:35 2013 type=SYSCALL msg=audit(1378976435.459:1123): arch=80000015 syscall=102 success=no exit=-13 a0=3 a1=3fffd74d1630 a2=6e a3=6f6e736f6c652e73 items=0 ppid=1 pid=3121 auid=1000 uid=1000 gid=1001 euid=1000 suid=1000 fsuid=1000 egid=1001 sgid=1001 fsgid=1001 ses=45 tty=(none) comm="qemu-system-ppc" exe="/home/rjones/d/qemu/ppc64-softmmu/qemu-system-ppc64" subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1378976435.459:1123): avc: denied { connectto } for pid=3121 comm="qemu-system-ppc" path="/home/rjones/d/libguestfs/tmp/libguestfsBIUB4k/console.sock" scontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket ---- time->Thu Sep 12 10:00:58 2013 type=SYSCALL msg=audit(1378976458.269:1130): arch=80000015 syscall=102 success=yes exit=0 a0=3 a1=3fffce09a060 a2=6e a3=6f6e736f6c652e73 items=0 ppid=1 pid=3979 auid=1000 uid=1000 gid=1001 euid=1000 suid=1000 fsuid=1000 egid=1001 sgid=1001 fsgid=1001 ses=45 tty=(none) comm="qemu-system-ppc" exe="/home/rjones/d/qemu/ppc64-softmmu/qemu-system-ppc64" subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1378976458.269:1130): avc: denied { connectto } for pid=3979 comm="qemu-system-ppc" path="/home/rjones/d/libguestfs/tmp/libguestfsQq0yC7/console.sock" scontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket Version-Release number of selected component (if applicable): selinux-policy-3.12.1-74.2.fc19.noarch How reproducible: Unknown. Everything works for days, then suddenly it stops working for no apparent reason. Steps to Reproduce: 1. Run 'libguestfs-test-tool'.
Labels of sockets etc: libguestfs: drwxr-xr-x. rjones rjones unconfined_u:object_r:user_tmp_t:s0 . libguestfs: drwxrwxr-x. rjones rjones system_u:object_r:tmp_t:s0 .. libguestfs: srwxrwxr-x. rjones rjones unconfined_u:object_r:user_tmp_t:s0 console.sock libguestfs: srwxrwxr-x. rjones rjones unconfined_u:object_r:user_tmp_t:s0 guestfsd.sock libguestfs: -rw-------. rjones rjones unconfined_u:object_r:user_tmp_t:s0 scratch.1 libguestfs: -rw-r--r--. rjones rjones unconfined_u:object_r:user_tmp_t:s0 snapshot2 libguestfs: -rwxrwxr-x. rjones rjones unconfined_u:object_r:user_tmp_t:s0 umask-check
audit2allow suggests: #============= unconfined_t ============== allow unconfined_t svirt_socket_t:unix_stream_socket connectto; Which raises some questions ... Surely unconfined can connect to anything (that being the point of unconfined)? Any why does this work some of the time but then suddenly stop working?
180c1f664e6f1950cb721a9dab34c1261b07a321 fixes this in git. The problem is we did not have any attributes on svirt_socket_t, so we did not define any relationship between unconfined_t and svirt_socket_t. By adding a domain_type(svirt_socket_t) we define this as a label on a process (which is not quite correct) but it at least gets it to work. Execute the following to get it working on your system, until the update arrives. # cat myvirt.te policy_module(myvirt, 1.0) gen_require(` type svirt_socket_t; ') domain_type(svirt_socket_t) # make -f /usr/share/selinux/devel/Makefile # semodule -i myvirt.pp Why it was working in the past and does not now, I don't know, unless there was a new version of libvirt?
Thanks, I can confirm that your workaround worked. I'm not sure why it just started happening. Although I didn't upgrade anything, it is possible that I restarted the libvirtd service, implicitly updating it to a newer version in the process. - - - As an aside, this is on a ppc64 box which has a few peculiarities of its own. It's big endian, 64 bit, and naked 'char' is unsigned (not signed as most other places). On this box, audit2allow prints: security: ebitmap: map size 256 does not match my size 64 (high bit was 216) I wonder if that's an endianness bug?
Back ported.
selinux-policy-3.12.1-74.4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-74.4.fc19
Package selinux-policy-3.12.1-74.4.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-74.4.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17007/selinux-policy-3.12.1-74.4.fc19 then log in and leave karma (feedback).
selinux-policy-3.12.1-74.4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.