From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: Mozilla uses the top level /tmp directory to store icon files. This creates problems for strict policy SELinux, where we are trying to restrict information flow from/to mozilla. In particular, we have designated the top level /tmp directory as a "content" location, where mozilla can store saved webpages. Any content stored there is labeled ROLE_untrusted_content_t automatically by SELinux. Reading and writing such content is subject to boolean restrictions, applied by the sysadmin. The idea is to prevent mozilla from saving potentially dangerous content on disk, or to prevent other applications from reading it. Content requires special interaction by the user to make it trusted. The point is, because of how SELinux works, all content saved in the directory is labeled in this way, including mozilla's icons. This has unintended consequences, such as mozilla not being able to load its icons, if it's disallowed to read content (whether trusted or untrusted). We might want to do that to prevent mozilla from obtaing information valuable to the user, and disclosing it over the web. This problem is partially created by SELinux inability to handle multiple transitions automatically, but at the same time, mozilla shouldn't be saving internal content in the top level /tmp folder. It would be better design practice if application-internal content, and user-visible content were separated. This is true for both top-level /tmp and top-level /home. So, to get to the point: Can mozilla be changed not to save internal content in the top level tmp directory. It should use its own private .mozilla folder, whether that's in /home, or in /tmp, to do its internal file management. It would be easier for us to handle $HOME/.mozilla, but we can also manage a private /tmp folder, if that's necessary. Also, can you clarify how printing is done in mozilla and thunderbird, because printing suffers from the exact same problem. Ivan Gyurdiev @ Red Hat SELinux Intern Version-Release number of selected component (if applicable): How reproducible: Didn't try Additional info:
... clicked submit twice, unfortunately... *** This bug has been marked as a duplicate of 160741 ***