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.