Bug 146832 - Mozilla content handlers: mplayer, totem
Mozilla content handlers: mplayer, totem
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-02-01 18:12 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-08 21:07:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-02-01 18:12:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
What is the plan for dealing with mozilla content handlers?
I am particularly interested in totem and mplayer.

mplayer right now does not transition to its domain,
and various denials show up.

totem produces the following denials:

totem reading /var/cache/gstreamer-0.8/registry*:
        user_mozilla_t denied { read } var_t:dir
        user_mozilla_t denied { getattr read } var_t:file

totem writing to /var/cache/dbus/system_bus_socket:
        user_mozilla_t denied { search } system_dbusd_var_run_t:dir
        user_mozilla_t denied { write } system_dbusd_var_run_t:sock_file
        user_mozilla_t denied { connectto }

totem execmod on /usr/lib/gstreamer-0.8/libgstffmpeg.so:
        user_mozilla_t denied { execmod } shlib_t:file

So, what should be done about those? 

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:

Additional info:
Comment 1 Daniel Walsh 2005-02-07 11:26:37 EST
Fixed in selinux-policy-strict-1.21.8-6
Comment 2 Ivan Gyurdiev 2005-02-08 21:07:00 EST
Closing bug, as there is a solution to this in Rawhide.
I will probably try to think of a better one if possible.

Particularly, maybe there should be a domain for totem as well,
with all the necessary permissions, and mozilla could switch to that.
The downside to having one large user_t domain, is that access rules
end up being too broad, involving all of user_t, and not the specific
app. Also, not having a totem domain means access rules can't be
focused in one place (since mozilla can't transition to user_t, so
rules for totem are duplicated between mozilla and user_t). 

That seems to be the benefit of the mplayer policy as well - if
there was no mplayer domain, mozilla would have to include
random mplayer rules in its policy. I am not sure I agree
with Russel Cooker's first response to this where he said that 
mplayer policy was of limited value, becaue it only provided 
access to rtc,and didn't add much else. Placing mplayer in its 
own domain seems to be consistent with selinux security goals
(isolation of applications, minimal priviledges to mplayer). It 
also provides a way to describe exactly what permissions should
be given to mozilla, for example, when executing mplayer.

...just my random thoughts on this subject matter.

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