RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 737790 - SELinux is preventing /usr/bin/spice-vdagent "write" access on spice-vdagent-sock
Summary: SELinux is preventing /usr/bin/spice-vdagent "write" access on spice-vdagent-...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.2
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 648553 682416
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-13 05:49 UTC by Qunfang Zhang
Modified: 2016-08-12 17:04 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.7.19-112.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 682416
Environment:
Last Closed: 2011-12-06 10:18:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1511 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-12-06 00:39:17 UTC

Comment 2 Miroslav Grepl 2011-09-13 05:59:52 UTC 
What exactly are you seeing? What AVC? The policy should work.
Comment 3 Qunfang Zhang 2011-09-13 06:24:44 UTC 
(In reply to comment #2)
> What exactly are you seeing? What AVC? The policy should work.

The problem is:
I installed a RHEL6.2 guest and load virtio serial driver, qxl driver and spice vdagent service inside guest.
But on the guest login screen, the mouse will be captured by the guest. After login to guest desktop, it can move out from guest freely.

Maybe I cloned a wrong bug, sorry for make the confusion and please correct me for that.
Comment 4 Qunfang Zhang 2011-09-13 06:27:13 UTC 
Additional info based on Comment 3.
I edit /etc/sysconfig/selinux in the vm and set "SELINUX=permissive" there and then reboot. After that the mouse should work correctly on the login screen.
Comment 5 Hans de Goede 2011-09-13 07:47:20 UTC 
(In reply to comment #4)
> Additional info based on Comment 3.
> I edit /etc/sysconfig/selinux in the vm and set "SELINUX=permissive" there and
> then reboot. After that the mouse should work correctly on the login screen.

Right, I deliberately wrote should there, so the question is, does it work on the login screen after making that change?

Because if it does, then there still is a selinux issue, but if it doesn't then there is something else amiss.
Comment 6 Qunfang Zhang 2011-09-13 07:56:03 UTC 
Hi, Hans
After modify the /det/sysconfig/selinux file and reboot, it works well on the login screen and mouse will not be captured any more.
Comment 7 Miroslav Grepl 2011-09-13 08:28:47 UTC 
Ok, what avc are you getting?

# ausearch -m avc -ts today
Comment 8 Qunfang Zhang 2011-09-13 08:56:13 UTC 
(In reply to comment #7)
> Ok, what avc are you getting?
> 
> # ausearch -m avc -ts today

Hi, Miroslav
[root@dhcp-66-83-73 ~]# ausearch -m avc -ts today
<no matches>
Comment 9 Miroslav Grepl 2011-09-13 09:53:33 UTC 
Ok, please boot in enforcing mode and execute the following steps

# setenforce 0
# semodule -DB

re-test it and

# ausearch -m avc -ts recent
Comment 10 Marian Krcmarik 2011-09-14 14:35:56 UTC 
(In reply to comment #9)
> Ok, please boot in enforcing mode and execute the following steps
> 
> # setenforce 0
> # semodule -DB
> 
> re-test it and
> 
> # ausearch -m avc -ts recent

70880-time->Wed Sep 14 10:33:26 2011
70911:type=SYSCALL msg=audit(1316010806.700:196): arch=c000003e syscall=4 success=no exit=-13 a0=406068 a1=7fff6f48e2e0 a2=7fff6f48e2e0 a3=7fff6f48dfb0 items=0 ppid=2652 pid=2656 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)
71295:type=AVC msg=audit(1316010806.700:196): avc:  denied  { getattr } for  pid=2656 comm="spice-vdagent" path="/dev/vport0p2" dev=devtmpfs ino=9980 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virtio_device_t:s0 tclass=chr_file
Comment 11 Marian Krcmarik 2011-09-14 16:08:18 UTC 
The latest spice-vdagent had to change its behaviour, I downgraded it to spice-vdagent-0.6.3-8.el6 version (the one we tested and tuned selinux policy last time) and the problem does not occur there.
Comment 12 Hans de Goede 2011-09-15 08:47:35 UTC 
(In reply to comment #11)
> The latest spice-vdagent had to change its behaviour, I downgraded it to
> spice-vdagent-0.6.3-8.el6 version (the one we tested and tuned selinux policy
> last time) and the problem does not occur there.

Right, the fix for bug 681797 makes the per user (and gdm) xsession agent process
retry connecting to the system level agentd process, to avoid it doing this
indefinitely on systems which don't have the agent channel, it now also does
a stat call on /dev/virtio-ports/com.redhat.spice.0 (which is a symlink to a
/dev/vport#p#) to check that the system is configured with the agent channel.

Seeing the AVC I believe this change is where this new AVC comes from.

Note it does not need actual access to the device, it just needs to be able to stat it.
Comment 13 Miroslav Grepl 2011-09-15 11:13:45 UTC 
OK.

Marian or Qunfang,
if you execute

# grep virtio /var/log/audit/audit.log |audit2allow -M myvdagent
# semodule -i myvdagent.pp


does it work then?
Comment 14 Marian Krcmarik 2011-09-15 11:51:53 UTC 
(In reply to comment #13)
> OK.
> 
> Marian or Qunfang,
> if you execute
> 
> # grep virtio /var/log/audit/audit.log |audit2allow -M myvdagent
> # semodule -i myvdagent.pp
> 
> 
> does it work then?

Yes
Comment 15 Miroslav Grepl 2011-09-15 11:56:22 UTC 
Great. Thanks.
Comment 21 errata-xmlrpc 2011-12-06 10:18:45 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1511.html
Note You need to log in before you can comment on or make changes to this bug.