Bug 155796 - Mozilla vs Esd - proper labeling for /tmp/.esd
Mozilla vs Esd - proper labeling for /tmp/.esd
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-23 08:45 EDT by Ivan Gyurdiev
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-13 07:36:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-04-23 08:45:14 EDT
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:
Comment 1 Daniel Walsh 2005-04-25 14:50:25 EDT
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.

Comment 2 Ivan Gyurdiev 2005-04-25 15:31:48 EDT
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 ... 
Comment 5 Daniel Walsh 2007-07-13 07:36:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.