SELinux should be off by default in FC3

[Sean Middleditch]

On Thu, 2004-10-07 at 12:56 -0400, Stephen Smalley wrote:
> On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote:
> > 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.

The point of the original question (as I interpreted it), is there value
in having mv, rename, and similar operations not update the file's
security context to the correct one of the new path?  In the case where
the file *should* have a different security context than other files
have by default in that path, then the user/admin can manually change
things.

The common operation should have the expected result.  So, the question
is, shouldn't the desired behavior of the mv, rename, and similar
operations be to update the context of the file by default?

> 
> > 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.

Most people do not complain about MAC due to the fact that it does what
it does.  Most complaints on SELinux are because it's far too complex to
get it to do what it does.  Complexity is the bane of security.  Lack of
education on security is the biggest security problem of them all.
SELinux adds a lot of complexity and increases the amount of education a
user/admin needs to operate a secured system.

The SELinux configuration syntax makes it vastly too difficult to
configure things for the common case.  The format makes it possible to
do just about anything, yes, but when you just know that binary foo only
needs to do X and Y to files A and B, it requires an extensive
background in SELinux to be able to configure properly.

Simplifying the config syntax could make SELinux far more usable.  The
current syntax requires the admin to think in terms of SELinux
mechanics, not in terms of what they want the system to do.  You can't
just write "/bin/foo can only perform read operations, and only
on /etc/foo.rc," you need to write, "/bin/foo is this
context, /etc/foo.rc is this context, and the traits between these are
this" and so on.  Low-level implementation details are directly exposed.
It's a poor design that only makes sense to the SELinux designers.
Think user interface design and usability.  The config files are the
SELinux user interface exposed to administrators.  It should be a syntax
and format that is ideal for how administrators think and the work they
want to do, not a syntax and format that is ideal for SELinux
developers.

A security system that is too complicated to use properly can be a lot
worse than a weaker security system that its users can easily understand
and configure.

Design the exposed UI for the end users of the system.  Don't just
expose the raw UI that developers understand.  And the config files are
definitely UI.

> 
> 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
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.