On Fri, 2004-04-30 at 10:39, Bill Rugolsky Jr. wrote:
I concur with that sentiment, and didn't mean to imply that a
relaxed
policy is not desirable. Not having to frantically rebuild a server
app the moment an exploit is discovered is reason enough to have SELinux
confining all network-facing servers. I only wanted to highlight that
expectations need to be reset as both the default policy has been loosened,
and the relaxed policy will loosen things further. I would hate for it
to reflect negatively on SELinux when someone exploits an FC2 default
SELinux install; the press will not make fine distinctions, and there
will be gloating from other corners. Toward that end, I think it is
important that users understand where along the "low-medium-high"
spectrum they have set their security.
One thing to consider is that the "relaxed" policy may actually end up
being more "secure" for the set of security goals it targets. Perhaps a
better term than "relaxed" would be "specialized" or
"targeted". Given
a small focused set of security goals, you can more easily specify the
policy and analyze it for exceptions. In contrast, when you try to put
every process in its own sandbox while supporting existing functionality
(particularly functionality that isn't used to living in sandboxes), it
becomes very difficult to analyze the resulting large, complex policy to
see whether it meets your higher level goals (e.g. don't let apache
subvert a trusted process).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency