Bug 1007309 - selinux unpredictably disallows access to socket
selinux unpredictably disallows access to socket
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
  Show dependency treegraph
 
Reported: 2013-09-12 05:09 EDT by Richard W.M. Jones
Modified: 2013-09-22 20:33 EDT (History)
4 users (show)

See Also:
Fixed In Version: selinux-policy-3.12.1-74.4.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-22 20:33:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2013-09-12 05:09:41 EDT
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'.
Comment 1 Richard W.M. Jones 2013-09-12 05:12:02 EDT
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
Comment 2 Richard W.M. Jones 2013-09-12 05:49:04 EDT
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?
Comment 3 Daniel Walsh 2013-09-12 13:54:56 EDT
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?
Comment 4 Richard W.M. Jones 2013-09-12 14:53:35 EDT
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?
Comment 5 Miroslav Grepl 2013-09-13 03:30:37 EDT
Back ported.
Comment 6 Fedora Update System 2013-09-16 13:15:27 EDT
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
Comment 7 Fedora Update System 2013-09-18 09:02:16 EDT
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).
Comment 8 Fedora Update System 2013-09-22 20:33:41 EDT
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.

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