Bug 436309
| Summary: | xguest is preventing firefox from executing openoffice.org | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Walsh <dwalsh> |
| Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | drepper, jnavrati |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-04-08 15:59:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
We followed http://people.redhat.com/drepper/selinux-mem.html to get ourselves some executable memory so we can make uno work, gcj does the same sort of thing, and probably firefox as well. The locations tried are $HOME followed by /tmp. Which makes it bizarre that it *does* work from the command line and not when firefox spawns off OOo. "xguest user is prevented from executing files in its home directory and /tmp" So, without firefox in the equation is openoffice.org able to launch directly as this xguest user ? I basically don't understand what distinction is made between the ran-by-firefox case and the ran directly case ? I don't see any possibility of removing the need for OOo to get some executable memory as we build vtables on the fly to connect C++ implementations to calls to uno interface slots, trampolining those calls to to the appropriate implementation slots or to proxies that translate to some other language implementation. No with the appropriate booleans set neither the firefox or the run directly would be allowed to execute files in the homedir/or tmpdir. Does openoffice need this no matter what? IE Can most docs be viewed without uno? We currently have openoffice labeled as a java app, to allow it to run java plugins and thus has execmem/execstack privs. It needs uno to do anything at all, OOo is just a bundle of uno components. And I've hacked the uno stuff to follow the double mmap suggestions that ulrich made in his selinux page. Uli you have any ideas? We need to have executable *somewhere*. either in the home dir or a special, user-writable directory. So far I suggested $HOME. If we want to defined something better then let's do it. Here are my options. I need to allow openoffice to execute files in homedir and /tmp. Currently openoffice is defined java_exec_t to allow it to execmem execstack so that it can run java code. I can allow xguest/xgues_mozilla_t/nsplugin_t to transition to xguest_java_t and allow java apps to execute homedir content. Or I can relabel openoffice to some new context openoffice_t which is allowed to executed files in the homedir, and has all the same privs as xguest + execmem +execstack +exec homedir. I am leaning tow (In reply to comment #7) > I need to allow openoffice to execute files in homedir and /tmp. Why "and"? Only one is needed and one can make a good argument for the former. /tmp is much more dangerous. From my side, just like libffi the last time I looked, the patched OOo tries $HOME followed by /tmp so or should work. Personally I'd even prefer a provided library or glibc call or sommat to just "do the right thing" and bump the details out of my app. So where do we stand with this. Is there any action I need to take from my side, or can this issue now be moved out of the OOo component. Current policy will allow openoffice to execute in the homedir. |
Description of problem: xguest user is prevented from executing files in its home directory and /tmp This is considered a security feature and would prevent certain attacks. Other new SELinux user types are being added which can use this feature. For some reason when firefox downloads a .doc file from the web it creates a temporary file and then uses openoffice to execute it. If you execute openoffice directly on the document it works. Here is the AVC of the error. type=SYSCALL msg=audit(03/06/2008 07:44:11.714:68) : arch=i386 syscall=mmap2 success=no exit=-13(Permission denied) a0=0 a1=1000 a2=5 a3=1 items=0 ppid=3078 pid=3088 auid=phyllis uid=phyllis gid=phyllis euid=phyllis suid=phyllis fsuid=phyllis egid=phyllis sgid=phyllis fsgid=phyllis tty=(none) comm=soffice.bin exe=/usr/lib/openoffice.org/program/soffice.bin subj=xguest_u:xguest_r:xguest_mozilla_t:s0 key=(null) type=AVC msg=audit(03/06/2008 07:44:11.714:68) : avc: denied { execute } for pid=3088 comm=soffice.bin path=/home/phyllis/.execoooRQgLao (deleted) dev=dm-0 ino=559591 scontext=xguest_u:xguest_r:xguest_mozilla_t:s0 tcontext=xguest_u:object_r:xguest_home_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/06/2008 07:44:11.714:69) : arch=i386 syscall=mmap2 success=no exit=-13(Permission denied) a0=0 a1=1000 a2=5 a3=1 items=0 ppid=3078 pid=3088 auid=phyllis uid=phyllis gid=phyllis euid=phyllis suid=phyllis fsuid=phyllis egid=phyllis sgid=phyllis fsgid=phyllis tty=(none) comm=soffice.bin exe=/usr/lib/openoffice.org/program/soffice.bin subj=xguest_u:xguest_r:xguest_mozilla_t:s0 key=(null) type=AVC msg=audit(03/06/2008 07:44:11.714:69) : avc: denied { execute } for pid=3088 comm=soffice.bin path=/tmp/.execooo5rJuNO (deleted) dev=dm-0 ino=4194394 scontext=xguest_u:xguest_r:xguest_mozilla_t:s0 tcontext=xguest_u:object_r:xguest_tmp_t:s0 tclass=file Why is firefox/openoffice using this temporary executable? Is this necessary? Is there a way to setup firefox/openoffice to execute openoffice ABC.doc instead? I am not sure if this is an openoffice or firefox problem.