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@xxxxxxxxxxxxxx> National Security Agency