Red Hat Bugzilla – Bug 467170
SELinux is preventing scalc.bin from changing a writable memory segment executable.
Last modified: 2008-10-16 10:05:11 EDT
Description of problem: With SELinux enforcing and allow_execmem set to false, scalc.bin causes a SELinux alert Version-Release number of selected component (if applicable): openoffice.org-calc-2.4.1-17.6.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Make sure SELinux is enforcing and allow_execmem is unset [semanage boolean --off allow_execmem] 2. Start openoffice spreadsheet 3. Look in audit log file or use setroubleshoot Actual results: From setroubleshoot - +++[cut]+++ Summary: SELinux is preventing scalc.bin from changing a writable memory segment executable. Detailed Description: The scalc.bin 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 scalc.bin 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 scalc.bin to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/lib64/openoffice.org/program/scalc.bin'". 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/lib64/openoffice.org/program/scalc.bin'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/lib64/openoffice.org/program/scalc.bin' Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:SystemLow- SystemHigh Target Context unconfined_u:unconfined_r:unconfined_t:SystemLow- SystemHigh Target Objects None [ process ] Source gnome-screensav Source Path /usr/libexec/gnome-screensaver-gl-helper Port <Unknown> Host xxx Source RPM Packages openoffice.org-calc-2.4.1-17.6.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-95.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execmem Host Name xxx Platform Linux xxx 2.6.26.5-45.fc9.x86_64 #1 SMP Sat Sep 20 03:23:12 EDT 2008 x86_64 x86_64 Alert Count 9 First Seen Wed 15 Oct 2008 13:47:01 BST Last Seen Thu 16 Oct 2008 07:58:20 BST Local ID 056ea6f4-cdfb-479d-8907-716459ae5099 Line Numbers Raw Audit Messages host=xxx type=AVC msg=audit(1224140300.345:2085): avc: denied { execmem } for pid=12645 comm="scalc.bin" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process host=xxx type=SYSCALL msg=audit(1224140300.345:2085): arch=c000003e syscall=9 success=no exit=-13 a0=2c7000 a1=34000 a2=7 a3=812 items=0 ppid=12634 pid=12645 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="scalc.bin" exe="/usr/lib64/openoffice.org/program/scalc.bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) ---[cut]--- Expected results: No SELinux violation, ideally by not changing the memory segment but at least by labeling soffice.bin correctly. Additional info:
You probably wanted to say [setsebool allow_execmem off] in step one. Nevertheless, I don't see any AVC. My selinux-policy is 3.1.1-97.fc9.x86_64 .
OOo follows the pattern of http://people.redhat.com/drepper/selinux-mem.html to get the executable memory that it needs. That hasn't been a problem with our selinux policies previously, so unless someone has changed our policies recently then more than likely the error is coming from some *other* library that OOo is linked to or dlopens and we get an error blaming OOo. So did you have any new openGL libraries, i.e. those of third parties like nvidia or something of that nature ?
This looks odd as well: " Source gnome-screensav Source Path /usr/libexec/gnome-screensaver-gl-helper Source RPM Packages openoffice.org-calc-2.4.1-17.6.fc9 " Why mention of scalc.bin and openoffice.org-calc (which match eachother) but then mention of "gnome-screensaver" and "/usr/libexec/gnome-screensaver-gl-helper" which match eachother, but not OOo. Maybe that adds weight to the theory of a common underlying opengl library issue
Comment #3 looks interesting and suggests to me that this may be a duplicate of Bug 465583 and Bug 467045 ?? Does OpenOffice interact with the screen saver in some way? I see the same message with the other OpenOffice applications but not with any other applications I have tried.
OOo knows about the screensaver so as to turn it off while a presentation is running full-screen, but I suspect it may be more to do with opengl, e.g. try running glxgears or some other opengl using application. I say a rawhide selinux package in todays rawhide report that mentioned an opengl labeling change/fix
Caolan McNamara said in Comment #2: > So did you have any new openGL libraries, i.e. those of third parties like > nvidia or something of that nature? Guilty as charged! I uninstalled the nvidia modules from Livna and I also uninstalled preload (which was gobbling up all the memory after the update) and now OOo is fine. Apologies for the false alarm :( Setting to Closed / NOTABUG (in Fedora).