Bug 436309 - xguest is preventing firefox from executing openoffice.org
xguest is preventing firefox from executing openoffice.org
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-06 09:01 EST by Daniel Walsh
Modified: 2008-04-08 11:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-08 11:59:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2008-03-06 09:01:37 EST
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.
Comment 1 Caolan McNamara 2008-03-06 09:14:11 EST
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.
Comment 2 Caolan McNamara 2008-03-10 08:55:52 EDT
"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.
Comment 3 Daniel Walsh 2008-03-10 10:21:09 EDT
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.
Comment 4 Caolan McNamara 2008-03-10 10:38:04 EDT
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.
Comment 5 Daniel Walsh 2008-03-10 11:03:31 EDT
Uli you have any ideas?
Comment 6 Ulrich Drepper 2008-03-10 16:52:41 EDT
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.
Comment 7 Daniel Walsh 2008-03-11 17:28:43 EDT
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
Comment 8 Ulrich Drepper 2008-03-12 17:10:13 EDT
(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.
Comment 9 Caolan McNamara 2008-03-12 18:54:18 EDT
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.
Comment 10 Caolan McNamara 2008-04-08 09:54:40 EDT
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.
Comment 11 Daniel Walsh 2008-04-08 10:40:04 EDT
Current policy will allow openoffice to execute in the homedir.

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