Description of problem: Cannot run vinagre with default SELinux policies. Version-Release number of selected component (if applicable): vinagre-2.24.1-1.fc10.x86_64 How reproducible: Very. Steps to Reproduce: 1. install vinagre 2. attempt to run 3. read the SELinux troubleshooting report Additional info: This may be a reoccurence of the previously closed "vinagre requires execmem" bug, which was marked as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=307531. Full alert: Summary: SELinux is preventing vinagre from changing a writable memory segment executable. Detailed Description: The vinagre application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If vinagre does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Allowing Access: If you trust vinagre to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/bin/vinagre'". You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t unconfined_execmem_exec_t '/usr/bin/vinagre'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/bin/vinagre' Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects None [ process ] Source nv-tmp-wvbMs2 Source Path /tmp/nv-tmp-wvbMs2 Port <Unknown> Host noel-fedora10 Source RPM Packages vinagre-2.24.1-1.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.13-8.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execmem Host Name noel-fedora10 Platform Linux noel-fedora10 2.6.27.4-58.fc10.x86_64 #1 SMP Mon Oct 27 17:47:43 EDT 2008 x86_64 x86_64 Alert Count 47 First Seen Thu 23 Oct 2008 01:30:43 PM EDT Last Seen Wed 29 Oct 2008 11:53:04 PM EDT Local ID 169909a5-c8fe-4bf0-ab2f-2f28b001f0d8 Line Numbers Raw Audit Messages node=noel-fedora10 type=AVC msg=audit(1225338784.396:69): avc: denied { execmem } for pid=7237 comm="vinagre" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process node=noel-fedora10 type=SYSCALL msg=audit(1225338784.396:69): arch=c000003e syscall=9 success=no exit=-13 a0=3110397000 a1=34000 a2=7 a3=812 items=0 ppid=1 pid=7237 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="vinagre" exe="/usr/bin/vinagre" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
I've got same version of vinagre & gtk-vnc installed, with SELinux in enforcing mode, and do not see any audit messages & it starts up without problems.
Daniel, I did a clean install, not having installed it previously, of vinagre last night, and am running on a relatively fresh install of Fedora 10 (rawhide) on which I have not made any change to SELinux policies. So this is pretty much as stock as it gets, with the exception of the nVidia 177.80 driver. What further information can I extract and provide to you? The problem is reproducible.
My money is on the libGL from NVidia requiring execmem.
Ah that would be a possibilty. The gkt-vnc 0.3.7 in Fedora is still using gktglext, which in turns links to libGL. If this is the problem, then the next gtk-vnc release which ditches GL in favour of Cairo will help.
Bastien, That might explain the execmem related hits I get for multiple things, of which vinagre and the Desktop Effects enabler seem the worst impacted. For those of us not entirely expert with granting SELinux policies, can I grant the execmem right to the effecting libGL, and if so, how? Or do I have to audit2allow for each application effected, even if the cause is a shared library? I have just run audit2allow for my entire audit log, and here are the results: # audit2allow < /var/log/audit/audit.log #============= bluetooth_t ============== allow bluetooth_t hald_t:dbus send_msg; allow bluetooth_t var_lib_t:file read; #============= cupsd_t ============== allow cupsd_t rpm_script_t:fifo_file write; #============= mount_t ============== allow mount_t etc_t:file write; #============= unconfined_t ============== allow unconfined_t self:process execmem; I have *not* activated that policy, yet. Waiting on advice, since I am trying to do the right thing for testing and improving of the released product.
Bastien, I appear to have confirmed your hypothesis. I uninstalled the nvidia driver, restarted X, ensured from Xorg.0.log that I was not using nvidia's GLX code, and was able to start vinagre. Daniel, when should we be expecting that new version of gtk-vnc? Soon, or at some more distant point in the future?
I'll close this bug. IMO, you should rather be contacting NVidia to fix their libGL...
Bastien, it would probably be best if Redhat worked with NVidia, vendor to vendor. In the meantime, the following commands address the problem: # chcon -t unconfined_execmem_exec_t /usr/lib64/xorg/modules/extensions/libglx.so # chcon -t unconfined_execmem_exec_t '/usr/bin/vinagre'