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
|
