Tue, 04 May 2010
Confining OpenOffice.org
I don't use OpenOffice.org except for occasionally reading a .doc
file people send to me instead of writing in plain text. I don't know
anything about its internals, and I only have a general feeling
that OO.org is a huge bloated mess[1]. Today I have attempted to confine OO.org
under SELinux in order to be able to convert untrusted documents
to PDF or HTML. I am still not done, but my experience so far has
brought the term "huge bloated mess" to a completely new level.
Here are few examples:
- OO.org is a spaghetti-like set of scripts, binaries and libraries calling each other, sometimes even via shell. So confining OO.org would mean to allow the shell to be executed under the domain which I want to confine it under. Talk about tightly specified rules.
- OO.org components communicate with each other over several different
transports: sometimes it uses an unnamed pipe, there are socketpairs,
and there is even a named socket under
/tmp. - Even though OO.org has configuration option for specifying the
directory under which temporary files are created, some of those files
are created directly under user's home directory, and some of them
under
/tmpno matter what. - OO.org even attempts to execute some of its temporary files!
- Even in batch mode, it still tries to read the
/mediadirectory.
On a positive side, OO.org with the -headless option now
finally can run without actually requiring a connection to the X server
(I have discovered it only after spending several hours writing a policy
for confining Xvfb. Oh well).
I wonder how many security holes in OO.org are waiting to be discovered, because I can't imagine at all how such a code base can be audited for security problems.
[1] Things like mixing Java, C, and their own scripting language for extensions, dialog windows which keep popping up no matter how many times I attempt to close them, their document recovery dialog, and other minor and major surprises.
2 replies for this story:
Adelton wrote: Shell
There's really no problem running the shell under the confined domain. It won't need to transition, just use the same domain as the calling process. As for the /media directory, it's mnt_t -- just dontaudit it if you are sure you won't need it, and you are done. In general, I wonder if Dan Walsh's sandbox or sandbox -X could be the thing you're looking for.
Yenya wrote: Re: Shell
I have of course already dontaudited mnt_t. But I still think it would be more tightly confined when no exec(2) would be required (and shell - as opposed to exec(2) of a simple program - is much worse). I have of course looked at sandbox (the new oo.org does not need -X).