SELinux should be off by default in FC3

[Stephen Smalley]

On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote:
> I think there is a strong point about complexity of the settings
> space. The fact that ownership permission and umask use a small finite
> settings space makes the ui for changing those settings managable
> across a number of tools.

Security contexts are simply security equivalence classes, i.e.
everything with the same security context is handled identically as far
as the security policy is concerned.  The permissions granted to a given
security context (the parallel to your DAC mode bits) are defined
centrally in the policy configuration, and you can analyze the entire
policy there, including the maximum possible privilege escalation and
information flows allowed.  Contrast with DAC mode bits or ACLs, where
the policy is effectively scattered throughout the filesystem and
neither privilege escalation nor information flow are bounded in any
way.

> For example lftp client understands chmod.   does it understand restorecon?

Not yet, AFAIK.  Nor will it likely ever if SELinux is disabled by
default and it remains limited to a very small user community.

> I think there is a point here too.. but let me rephrase it by asking a
> question.  Is there ever any value in having files in a path NOT be
> the correct security context for that path?

Yes, there is value in customizing your file contexts beyond the default
settings.

> Are there tools in userspace with 'reasonable' ui that would let a
> user manually change context on a subset of files contrary to what
> restorecon would do?  If there is a lack of tools that let users
> delibrately create out of sync security contexts, thats a major
> difference between how ownership and permissions are handled.

chcon(1) is the equivalent to chown/chmod.  

Mandatory access control is a (to steal a term) disruptive technology,
but one that is fundamentally necessary if one is ever going to be able
to effectively control or even reliably monitor what is truly happening
on computing systems.  With only DAC, the code that acts on our behalf
operates without any restraint and with precious little protection
against subversion.  If you want to have a hope of confining the damage
caused by flawed and/or malicious program, protecting your application
security mechanisms against tampering and bypass, separating your
sensitive information from your public information, protecting
information on which your operations depend from corruption, or ensuring
that your data is processed as required, then MAC is a necessary
building block, not optional.

As far as freedom is concerned, one always has the option of disabling
SELinux at install time or post-install; I don't think anyone has any
plans to change that.  But disabling by default has a huge impact on
uptake of this disruptive technology and on bringing sufficient
resources to bear to fully integrate it into the entire system.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency