Bug 146832
| Summary: | Mozilla content handlers: mplayer, totem | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ivan Gyurdiev <ivg231> |
| Component: | selinux-policy-strict | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-02-09 02:07:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Fixed in selinux-policy-strict-1.21.8-6 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. |
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 } system_dbusd_t:unix_stream_socket 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): selinux-policy-strict-1.21.5-5 How reproducible: Didn't try Steps to Reproduce: Additional info: