If we cannot move the moz/ffox/tbird into their own domain then, yes,
disable the checks for unconfined processes. But we should keep the
tests for all programs which have their own domain.
Moz/ffox/tbird cannot be moved into their own domain until we have the
capability to launch content handling applications from within firefox,
and have them enter the proper domain. This is particularly difficult,
because some of those applications (i.e. openoffice) don't have a domain
at the moment (and creating one would be difficult). That means firefox
must be allowed to transition into user_t/unconfined_t, which defeats
any attempt at security. Launching one application within another is the
primary reason why the desktop can't be confined.
In the old strict policy firefox and mozilla were confined, and I worked
on the evolution and thunderbird policies over the summer. I think the
basic functionality was working, but those programs could not be allowed
to launch other apps. We need a trusted program to be responsible for
that, so that firefox can't transition into the generic domain.
There's other problems as well, including limiting those programs'
ability to write to the user home directory, and the top level /tmp
directory (what good does confining an application do, if it can still
overwrite all your important files, or steal your credit card info?).
There's marking of content as potentially hostile, and management of
that content.
There's an effort to limit bonobo connections from firefox to restricted
domains only (no user_t/unconfined_t connections).... also challenging,
because there's so many things firefox talks to, and one of them is
sufficient to necessitate allowing communications channel to
user_t/unconfined_t.
=============
Currently the firefox/moz/tbird/evolution policies have not been ported
yet to the new refpolicy. They also require the policies for bonobo,
orbit, gnome and other dekstop-related things (also not yet ported).
Even when they are ported, I doubt they would meet the needs of
targeted-policy users.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
