Evolution: OpenOffice / Firefox integration problems

[Ted Rule]

I've noted before that Evolution has some some problems launching
OpenOffice with SELinux enforcement in place.

After some further experimentation with different policy settings, and
also different sequences of opening and closing OpenOffice from GNOME
and/or Evolution, some more findings. I've also found a similar issue
relating to Firefox launching from Evolution.

As mentioned before, I still need various extra permissions
on /var/spool so as to be able to read Unix mail spools from Evolution:

allow user_evolution_t var_spool_t:dir { search };
allow user_evolution_t mail_spool_t:dir { read getattr search };
allow user_evolution_t mail_spool_t:file { read getattr write };

I still need an extra execmem permission so as to be able to launch
OpenOffice from Evolution's user_evolution_t domain:

allow user_evolution_t self:process { execmem };

So as to avoid extra permissions on the user_t domain, I add a
transition to the user_evolution_t domain for the Unix socket
in /tmp/OSL_PIPE_500_SingleOfficeIPC_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

type_transition user_evolution_t tmp_t:sock_file user_tmp_t;

The transition ensures that OpenOffice in user_t and from
user_evolution_t create the socket in the same user_tmp_t domain.

We add extra permissions so as to allow OpenOffice opened from
Evolution, (Evo/OO), to write/delete/create the socket:

allow user_evolution_t { user_tmp_t }:sock_file { getattr write unlink
create };

We add an "optional" permission for OpenOffice opened from GNOME,
( raw/OO ), to be able to connect to the socket created by Evo/OO.

allow user_t user_evolution_t:unix_stream_socket { connectto  };

For completeness, it should be noted that the policy ALREADY contains
the following permission:

allow user_evolution_t user_t:unix_stream_socket { connectto  };

i.e. "connect backwards".

Without ALL of the extra permissions in the user_evolution_t domain,
Evo/OO fails to launch. It is apparent from the logs that it does fire
up, but once it spots the "broken" socket permissions, it shuts down
again.

With the combination of these extra permission in place, we find the
following behaviour.

If I launch Evo/OO with no copy of raw/OO already running, the Evo/OO
process runs in the user_evolution_t domain. It first of all tries to
write to the socket - which still exists in /tmp courtesy of the last
invocation of raw/OO not 'cleaning up'. Probably because of catching an
EPIPE or similar signal, it finds no-one listening on the socket, and
proceeds to unlink/create a fresh socket. Just for luck, it then writes
to it.

If I then launch raw/OO with the Evo/OO already running, a new user_t
swriter.bin process launches. Once running, it then appears to write to
the existing user_evolution_t socket. As best I can judge, it then
"pumps" the raw/OO document through the socket, whereupon it is visible
in a 2nd Window running under the Evo/OO instance. Once the "pumping"
has finished, the raw/OO process closes. This leaves the raw/OO document
open inside the Evo/OO process.

This leads to a significant problem. The 'raw/OO' document is now marked
as "read-only", because if you've opened a user_home_t file, Evolution
has no write permissions to the original file. The user "experience" is
thus confused by a window which was apparently opened with sufficient
permissions to edit the file being swapped for a window which has no
such permissions.

Conversely, if I launch Evo/OO with raw/OO already running, Evo/OO
"connects back" to raw/OO via the existing socket and pumps the Evo/OO
attachment into the raw/OO user_t process. At which point, of course,
the Evo/OO user_evolution_t process closes, leaving the attachment open
inside a process with "elevated" user_t permissions.

If this permission:

allow user_t user_evolution_t:unix_stream_socket { connectto  };

is removed from the mix, then when launching raw/OO after Evo/OO is
already open, it finds that it can't connect to the current socket and
the document opens in a user_t window/process, with the original
attachment open in a user_evolution_t window/process. If raw/OO is
closed before Evo/OO, raw/OO still has sufficient permissions on the
socket to confuse the Evo/OO instance, and Evo/OO fails to shut down
cleanly, requiring a "Force Quit" dialog box.

Having seen all of this behaviour, a number of potential corrective
measures occur to me, some of which are OpenOffice rewrites, and some of
which are SELinux policy changes.

1. If OpenOffice were recoded to gracefully allow for a situation where
it had no rights to open/write/delete the Unix domain socket, the Evo/OO
process/window could launch without error, and display the attachment
with user_evolution_t permissions. This would allow two processes - one
in user_t and one in user_evolution_t to run side by side, and would
avoid the need for any extra user_evolution_t permissions diluting the
strength of the policy.

2. OpenOffice should probably be corrected to remove the socket upon
shutdown rather than rely on system reboot or tmpwatch to do the job.

3. From what I can see, I assume that the socket name is constructed
from my Unix login id, and hence is unique to each login on the system.
If OO were more SELinux aware it would construct the name based on
login.SELinux-domain so that multiple attachment windows could share a
user_evolution_t process, whilst a different socket allowed different
documents to share a user_t process. This would probably be more
difficult to code than 1.

4. The attachment is temporarily saved in
~/.evolution/cache/tmp/xxxxxx, and hence is created in the
user_evolution_home_t domain. When Evo/OO launches, it would appear to
have write permissions to the temporary copy. This feels wrong to me.
Surely the "attachment viewer" process should only have read permissions
on the original attachment. Sadly, this seems to require the creation of
some sort of user_evolution_viewer_t domain for Evo/OO to run inside. A
positive side-effect of this would be that the domain's networking
permissions could be cut back as compared to user_evolution_t; a viewer
domain would surely never need rights to speak IMAP/POP3 for instance.

5. The user_evolution_t domain appears to already have this set of
permissions into the user_t domain:

allow user_evolution_t user_t:unix_stream_socket connectto;
allow user_evolution_t user_t:unix_stream_socket { read write };

The corresponding permissions in the other direction:

allow user_t user_evolution_t:unix_stream_socket connectto;
allow user_t user_evolution_t:unix_stream_socket { read write };

don't exist in the default policy. The former seems to be a side-effect
of the ice_connect macros used by gnome_application macro. I can see
there are some FIXMEs scattered in the ice_macros policy, so I presume a
more specific ice domain fix is in hand.


Having surmised what was happening with OpenOffice inside Evolution,
I've had a look at what happens with Firefox opening a URL from
Evolution, and Evince opening a PDF attachment from Evolution.

With Evince, the operation is much cleaner. A separate user_evolution_t
Evince process is launched irrespective of whether a user_t Evince
process already exists. There is still the issue of the original
attachment being read/write to the user_evolution_t Evince process, of
course.

With Firefox, a new window is created if a user_mozilla_t Firefox
process already exists, but "of course", the window is shared with the
single user_mozilla_t firefox.bin process. 

If no Firefox process already exists, the Evolution silently fails to
open the URL. The policy appears to already allow for Evolution to
launch Firefox courtesy of the mail_client_domain macro, so this appears
to be an actual bug in the policy somewhere.

FWIW, the firefox scripts detect whether another process exists, and
launch "mozilla-xremote-client" instead if it does and firefox-bin if it
doesn't.

Following the trail of error messages that I can find, it seems that the
failure relates to an inability to find various shared libraries, which
in turn points to a missing LD_LIBRARY_PATH. By symlinking various
mozilla libraries into /usr/lib, I can work round most of the errors,
but this is not a proper fix.

/usr/lib/firefox-1.0.7/firefox-bin: error while loading shared
libraries: libmozjs.so: cannot open shared object file: No such file or
directory

Searching for the launch path for firefox, we find that /usr/bin/firefox
is a script which launches other scripts and binaries
in /usr/lib/firefox and /usr/lib/mozilla...

The gotcha which caught my eye was that the script /usr/bin/mozilla has
a mozilla_exec_t label, whilst /usr/bin/firefox is labelled bin_t.
Eventually /usr/bin/firefox calls /usr/lib/firefox-1.0.7/firefox-bin
which is marked mozilla_exec_t.

I therefore reasoned that the LD_LIBRARY_PATH setting was lost in the
domain transition from /usr/bin/firefox running in user_evolution_t
to /usr/lib/firefox-1.0.7/firefox-bin running in user_mozilla_t.

By relabelling /usr/bin/firefox as mozilla_exec_t, I can now launch
firefox from Evolution under all circumstances. This means that the PATH
setup in /usr/bin/firefox is preserved as no domain transition takes
place when invoking firefox-bin - it occurs when Evolution
calls /usr/bin/firefox instead. This may not be the best fix, but given
that the /usr/bin/mozilla script has a mozilla_exec_t label, it seems
reasonable to me.


-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/