Description of problem: There are hundreds of SELinux denials when I try to export an odt document to DocBook from OpenOffice.org Writer: SELinux is preventing swriter.bin from changing the access protection of memory on the heap. The swriter.bin application attempted to change the access protection of memory on the heap (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 web page explains how to remove this requirement. If swriter.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 against this package. Raw audit messages: host=redbull type=AVC msg=audit(1268941411.430:2578): avc: denied { execheap } for pid=19796 comm="swriter.bin" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process host=redbull type=SYSCALL msg=audit(1268941411.430:2578): arch=40000003 syscall=125 success=no exit=-13 a0=8052000 a1=482000 a2=5 a3=bfdbed50 items=0 ppid=19786 pid=19796 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=280 comm="swriter.bin" exe="/usr/lib/openoffice.org/program/swriter.bin" subj=user_u:system_r:unconfined_t:s0 key=(null) Version-Release number of selected component (if applicable): openoffice.org-writer-2.3.0-6.11.el5_4.4 selinux-policy-2.4.6-255.el5_4.4 How reproducible: always Steps to Reproduce: 1. Open this document with swriter -> http://gnome.cult.bg/usermanual/2.10/gnome2-10-book.odt This is a localized GNOME user guide. 2. After opening go to File -> Save as and select DocBook 3. Click Save Actual results: SELinux denial, CPU usage goes to 100% Expected results: No denial, file is saved as DocBook xml. Additional info: Putting SELinux in permissive mode let me save the file as docbook.
OOo won't be directly involved here, it follows the prescribed pattern of the double mmap for the executable memory that it needs. This'll more than likely be whatever java is in use (check tools->options->java to see which one it is), perhaps unexpectedly but legitimately being used via a dlopened libjvm.so.
Java is Sun Java 1.6.0_18
If you trust this application, you can turn off the check by turning on the allow_execheap boolean # setsebool -P allow_execheap 1 This will allow any unconfined processes to execheap. I think in RHEL5.5 openoffice will run as unconfined_execmem_t. If you installed RHEL5.5 policy you could just add access to unconfined_execmem_t using audit2allow. Suns Java should not require execheap, but we can not fix this.