From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3 Description of problem: Mozilla wants to connect to port 16001 (esd) and read/write to /tmp/.esd/socket. This is labeled sysadm_tmp_t on my system. What *should* it be labeled? audit(1114245487.510:0): avc: denied { name_connect } for pid=1506 exe=/usr/lib/firefox-1.0.3/firefox-bin dest=16001 scontext=phantom:staff_r:staff_mozilla_t tcontext=system_u:object_r:port_t tclass=tcp_socket audit(1114245487.591:0): avc: denied { write } for pid=3061 exe=/usr/bin/esd name=.esd dev=dm-0 ino=827685 scontext=phantom:staff_r:staff_mozilla_t tcontext=root:object_r:sysadm_tmp_t tclass=dir audit(1114245487.510:0): avc: denied { read write } for pid=1506 exe=/usr/lib/firefox-1.0.3/firefox-bin name=socket dev=dm-0 ino=827686 scontext=phantom:staff_r:staff_mozilla_t tcontext=root:object_r:sysadm_tmp_t tclass=sock_file Version-Release number of selected component (if applicable): selinux-policy-strict-1.23.12-1 How reproducible: Didn't try Steps to Reproduce: Additional info:
These are the types of places where I think Mozilla policy is broken. I think if you want to use mozilla/firefox in this way you disable the trans. Otherwise we are constantly finding things broken in Mozilla until we fix it up to be able to do everything user_t can do. IE Useless. We should select a security profile for web browsing and if the customer can not handle it, disable the transition.
Well, the .esd folder is not labeled properly (on my system) regardless of mozilla. If I type "esd" I get denials, because staff_t can't access sysadm_tmp_t. ===================== Regarding mozilla - I'm not sure this is true. The way I imagine things is - we restrict interaction of mozilla to things that are not in user_t. Upon execution of plugin code, tranisition to an alternate domain to deal with each plugin. For example, the mplayer plugin. Also, I think those domains should be separate from the ROLE_app_t domains - the mplayer plugin domain should be more confined than the default mplayer policy (which is not true now). I think once ROLE_tmp_t and ROLE_home_t access is denied to mozilla, the policy will be much more secure. However first I must figure out how ORBit works, and there's no time to do that now - exams ...
I think the amount of stuff labeled in /tmp is un fixable and I am closing this bugzilla. I am going a different route in confining mozilla.