SELinux is preventing /usr/bin/spice-vdagent from 'getattr' accesses on the chr_file /dev/vport0p1. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that spice-vdagent should be allowed getattr access on the vport0p1 chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep spice-vdagent /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:virtio_device_t:s0 Target Objects /dev/vport0p1 [ chr_file ] Source spice-vdagent Source Path /usr/bin/spice-vdagent Port <Unknown> Host (removed) Source RPM Packages spice-vdagent-0.8.1-1.fc16 Target RPM Packages Policy RPM selinux-policy-3.10.0-5.fc16 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.0-0.rc7.git3.1.fc16.x86_64 #1 SMP Fri Jul 15 22:56:12 UTC 2011 x86_64 x86_64 Alert Count 4 First Seen Mon 18 Jul 2011 10:19:44 AM MDT Last Seen Tue 19 Jul 2011 09:50:36 AM MDT Local ID 92e1e98b-b836-4342-a828-9a80f2feb015 Raw Audit Messages type=AVC msg=audit(1311090636.899:38): avc: denied { getattr } for pid=1013 comm="spice-vdagent" path="/dev/vport0p1" dev=devtmpfs ino=6145 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virtio_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1311090636.899:38): arch=x86_64 syscall=stat success=no exit=EACCES a0=405f08 a1=7fffcf7e8cd0 a2=7fffcf7e8cd0 a3=3056895120 items=0 ppid=1004 pid=1013 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm=spice-vdagent exe=/usr/bin/spice-vdagent subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: spice-vdagent,xdm_t,virtio_device_t,chr_file,getattr audit2allow #============= xdm_t ============== allow xdm_t virtio_device_t:chr_file getattr; audit2allow -R #============= xdm_t ============== allow xdm_t virtio_device_t:chr_file getattr;
I started up my x86_64 spice-using virtual machine. I logged in as an ordinary user. I then realized that I had a system maintenance task that needed to be done, so I started a terminal and typed "su -" in it. There was a long pause, and then the setroubleshoot icon popped up and showed me this denial. I ran "restorecon -v" on both /usr/bin/spice-vdagent and /dev/vport0p1 with no change.
Did everything seem to work correctly? If not please put the machine into permissive mode and collect all of the AVC messages.
Created attachment 513861 [details] List of AVC denials after "su -" Other than the long pause before I got my root shell, yes, everything seemed to work normally. Just in case, though, I did a full relabel (which didn't relabel anything) and rebooted in permissive mode. After attempting to "su -" in a terminal, I again got this alert, as well as 4 others from systemd-logind. The attached file has the details. Process 734 is systemd-logind, and process 1592 is the process running "su -", by the way.
"su -" issue will fix in the next rawhide release which I am going to build today. Looks like allow xdm_t virtio_device_t:chr_file getattr; could be dontaudited.
It's fixed in the sense that I don't see any AVC denials now, but "su -" used to be nearly instantaneous, and now pauses for 25 seconds. I did an strace to see what it's blocking on: socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 5 connect(5, {sa_family=AF_FILE, path="/var/run/dbus/system_bus_socket"}, 33) = 0 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 geteuid() = 0 getsockname(5, {sa_family=AF_FILE, NULL}, [2]) = 0 poll([{fd=5, events=POLLOUT}], 1, 0) = 1 ([{fd=5, revents=POLLOUT}]) sendto(5, "\0", 1, MSG_NOSIGNAL, NULL, 0) = 1 sendto(5, "AUTH EXTERNAL 30\r\n", 18, MSG_NOSIGNAL, NULL, 0) = 18 poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}]) read(5, "OK 677651fec9996da27413a0ee00000"..., 2048) = 37 poll([{fd=5, events=POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}]) sendto(5, "NEGOTIATE_UNIX_FD\r\n", 19, MSG_NOSIGNAL, NULL, 0) = 19 poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}]) read(5, "AGREE_UNIX_FD\r\n", 2048) = 15 poll([{fd=5, events=POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}]) sendto(5, "BEGIN\r\n", 7, MSG_NOSIGNAL, NULL, 0) = 7 poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}]) sendmsg(5, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\1\0\0\0n\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128 clock_gettime(CLOCK_MONOTONIC, {480, 591986248}) = 0 poll([{fd=5, events=POLLIN}], 1, 25000) = 1 ([{fd=5, revents=POLLIN}]) recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\n\0\0\0\1\0\0\0=\0\0\0\6\1s\0\5\0\0\0:1.88\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 260 recvmsg(5, 0x7fff86cddb50, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) sendmsg(5, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1d\0\0\0\2\0\0\0\226\0\0\0\1\1o\0\27\0\0\0/org/fre"..., 168}, {"\364\1\0\0\242\6\0\0\4\0\0\0su-l\0\0\0\0\3\0\0\0tty\0\0\0\0\0"..., 100}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 268 clock_gettime(CLOCK_MONOTONIC, {480, 595443380}) = 0 poll([{fd=5, events=POLLIN}], 1, 25000) = 0 (Timeout) This didn't happen prior to a few days ago, when the AVC denial started showing up. Is there any possibility that the failure to read from /var/run/dbus/system_bus_socket is SELinux related? If not, I guess I get to go file another bug. Thanks.
Put the machine in permissive mode and see if the delay goes away. # setenforce 0 If it does not go away it is probably not SELinux related, if it does, then it is probably our fault.
The delay disappears in permissive mode. I'm willing to debug, but I'll need a kick in the right direction. Thanks.
The delay is fixed in the latest Rawhide.
Description of problem: Starting Gnome Shell session Version-Release number of selected component: selinux-policy-3.13.1-168.fc24.noarch Additional info: reporter: libreport-2.6.3 hashmarkername: setroubleshoot kernel: 4.5.0-0.rc0.git7.1.fc24.x86_64 type: libreport
Description of problem: Starting a session Version-Release number of selected component: selinux-policy-3.13.1-169.fc24.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.5.0-0.rc3.git0.1.fc24.x86_64 type: libreport