Ted Rule wrote:
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).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 };
-- -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
