Bug 160741

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: