Evolution - /var/spool and OpenOffice launching

[Daniel J Walsh]

Ted Rule wrote:
> After some more trawling through the policy for dontaudit references, I
> found that I needed to add the following:
>
> allow user_t { user_tmp_t tmp_t}:sock_file { getattr };
> allow user_evolution_t { user_tmp_t tmp_t}:sock_file { getattr };
>
> in addition to my existing patch granting { create write unlink }
> permissions to get OO to launch from Evo.
>
> As mentioned before, it seems that OO launched from user_t creates the
> socket as user_tmp_t, whereas when launched from user_evolution_t, OO
> creates the socket as tmp_t. Hence there is possibly still some tidyup
> to do to the evolution policy to make sure the socket is always created
> user_tmp_t?
>
> Now that I can launch OO from Evolution, another little problem has
> become apparent. If I launch OO from Evo, then launch OO natively from
> user_t, then close the native OO instance, I find that the
> user_evolution_t OO instance can't be closed cleanly. The process list
> before trying to close either shows two different copies of swriter.bin
> in user_t and user_evolution_t domains, but of course the sock_file
> appears to be shared by both instances with the same filename. Some more
> experimentation may reveal how to tweak SELinux to allow for a clean
> close of both instances, but I would imagine this is at best a fudge.
>
>
>
> On Fri, 2005-10-14 at 14:05 +0100, Ted Rule wrote: 
>   
>> I have a couple of problems with Evolution/OpenOffice running on
>> FC4/strict with policy:
>>
>> selinux-policy-strict-sources-1.27.1-2.3
>>
>> The first, relatively simple, issue is that the user_evolution_t policy
>> doesn't seem to have provision for reading /var/spool/mail. I have
>> sendmail setup to forward root mail to my local non-root account, and
>> then Evolution setup to read the ensuing Unix mail spool locally in
>> addition to my remote IMAP/POP3 accounts.
>>
>> The extra var_spool_t and mail_spool_t policy listed below seems to do
>> the trick, though obviously a more complete solution would require
>> proper "macro-ising" to take account of staff_evolution_t and so on.
>>
>> As far as I can tell, there isn't a boolean switch to allow for this.
>>
>>
>> The second, slightly more intractable problem is that of
>> OpenOffice/Evolution integration.
>>
>> I have the allow_execmem boolean enabled to allow for a plain launch of
>> OpenOffice, but I find that an additional execmem policy - see below -
>> is needed to allow for the launch of OO from within Evolution's
>> "attachment view dialog" as it now has its own user_evolution_t domain
>> which seems to ignore the allow_execmem boolean.
>>
>> The execmem policy is still not sufficient to allow me to launch OO from
>> Evolution. I've added some extra policy to cope with denial messages
>> that I've seen for this socket file
>>
>> /tmp/OSL_PIPE_500_SingleOfficeIPC_2df8e6ac565346ee4ccc8ac992ddaa83
>>
>> which OO creates, but this is still not enough to make OO fire up.
>>
>> The socket created by OO appears to get left behind once OO has
>> finished, which makes me suspect that part of the problem is that the
>> socket has a different file_context when created from user_t as opposed
>> to user_evolution_t.
>>
>> With my current patched policy, I get no further SELinux denial
>> messages, so debugging the problem has become trickier. Presumably there
>> is a dontaudit policy somewhere suppressing the error message I'm
>> interested in, but I haven't tracked it down yet.
>>
>> Any suggestions, folks?
>>
>>
>> Current patches to strict policy:
>>
>> =================================================================
>>
>>
>> cat /etc/selinux/strict/src/policy/domains/program/localpolicy.te
>> # Miscellaneous Local SELinux policy not
>> # covered by other .te configuration
>> ...
>>
>> ##############################################################
>> # Patch to allow Evolution to read home mail spools
>> # Seemingly still required as not included in default policy
>> 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 };
>>
>> ...
>>
>> #############################################################
>> # Patch to allow Evolution to launch OpenOffice....
>> allow user_evolution_t self:process { execmem };
>> auditallow user_evolution_t self:process { execmem };
>>
>> #############################################################
>> # Patch to allow OpenOffice to write to a temporary socket....
>> allow user_t { user_tmp_t tmp_t}:sock_file { create write unlink };
>> auditallow user_t { user_tmp_t tmp_t}:sock_file { create write unlink };
>>
>> ...
>>
>> # Patches to allow OpenOffice to write to a temporary socket....from
>> Evolution
>> allow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write
>> unlink };
>> auditallow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write
>> unlink };
>>
>>
>>     
>
>   
Ted, You are coming to the point where Usability and Security crash.  
One of the problems with using Strict policy to protect applications 
like Firefox and Thunderbird/Evolution.  Is users want the application 
to run as it always did but prevent it from doing evil things.   

In my opinion you need to define a very strict way of running 
Firefox/Thunderbird/Evolution or you run them in the default user 
context.  If you want them to be able to run Open Office, RPM, or any 
other application that is associated with a file type, the policy for 
Firefox and Thunderbird quickly expands to the policy for user_t.  So 
you gain no protection.  Now if you define a security policy that says 
Firefox can only read html content and can only download to ~/My 
Downloads or /tmp.  We can start to lock the app down.  Similarly we can 
lock down your mail clients.  But if you do not have the authority to 
lock down these apps you might as well run them as user_t (Disable Trans).



--