On Fri, 2004-04-30 at 09:33, Bill Rugolsky Jr. wrote: > While I think that a relaxed policy might be useful to server admins who > would rather not fix their admin scripts, etc., the full policy ought not > be terribly burdensome on a dedicated server. > > It is on the desktop that SELinux potentially offers the greatest benefit > and the greatest burden. Client apps (and particularly GUI client apps) -- > browser, e-mail, IM, media players, will be targeted. We laugh at poor > MS Outlook users, but social engineering works. A measurable fraction of > Linux users will inevitably read their e-mail and follow that link, > look at that picture or video clip, play that game applet, etc. It > is the client apps that need confinement. > > While exploiting a client app doesn't immediately give the attacker > admin privileges, that's largely irrelevant if the purpose of the > attack is to (1) harvest, destroy, or modify the user's data, or (2) > use the client at a zombie for some purpose. > > Confining Postfix and not Mozilla is like double-locking the front door, > but leaving the bathroom window open. And yet the default tunable settings in the Fedora policy effectively undo much of the benefit of the example mozilla policy (see 'readhome' and 'writehome'). Yes, you can change those tunable settings. But offering a separate relaxed policy doesn't mean that you can no longer choose a strict policy; it just means that the relaxed policy can be greatly simplified (as you can collapse many domains and types together), will be much easier to get right (thus avoiding users disabling SELinux entirely), and won't keep "leaking" weakness into the strict policy. It also makes the choice clear to users. SELinux provides flexible support for security policies in recognition of the fact that a single policy won't meet everyone's desires or needs. Forcing everyone to use a single security policy (even a single policy with small variations via tunables) runs counter to the point, and seems to be leading to SELinux disabled by default. That will ultimately lead to ever greater divergence and compatibility issues between the SELinux-enabled state and the SELinux-disabled state, effectively yielding two different systems like the old trusted vs. mainstream product separation of old. Better to have SELinux enabled all the time with two different policies that are appropriately tuned to the needs and desires of differing user communities. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
