Bug 469135 - Vinagre will not run do to violation of valid SELinux policies (execmem)
Vinagre will not run do to violation of valid SELinux policies (execmem)
Product: Fedora
Classification: Fedora
Component: vinagre (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-30 00:01 EDT by Noel J. Bergman
Modified: 2008-10-31 15:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-30 17:02:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Noel J. Bergman 2008-10-30 00:01:20 EDT
Description of problem:

Cannot run vinagre with default SELinux policies.

Version-Release number of selected component (if applicable):


How reproducible:


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:


SELinux is preventing vinagre from changing a writable memory segment

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
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
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 #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)
Comment 1 Daniel Berrange 2008-10-30 07:01:25 EDT
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.
Comment 2 Noel J. Bergman 2008-10-30 09:35:47 EDT

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.
Comment 3 Bastien Nocera 2008-10-30 09:51:23 EDT
My money is on the libGL from NVidia requiring execmem.
Comment 4 Daniel Berrange 2008-10-30 10:03:55 EDT
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.
Comment 5 Noel J. Bergman 2008-10-30 12:27:31 EDT

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.
Comment 6 Noel J. Bergman 2008-10-30 15:42:26 EDT
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?
Comment 7 Bastien Nocera 2008-10-30 17:02:43 EDT
I'll close this bug. IMO, you should rather be contacting NVidia to fix their libGL...
Comment 8 Noel J. Bergman 2008-10-31 15:30:10 EDT
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'

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