Expectation Management for Test Releases

[Will Backman]

On Fri, 2004-04-23 at 15:39, Tom Mitchell wrote:
> On Tue, Apr 20, 2004 at 04:19:40PM -0400, Elliot Lee wrote:
> > On Tue, 20 Apr 2004, Chris Adams wrote:
> > 
> > > Once upon a time, Will Backman <whb at ceimaine.org> said:
> ....
> > > major changes of kernel 2.6 and SElinux); I'm not sure it is realistic
> > > though.
> ....
> > Some may not yet be aware that SELinux is going to be disabled by default
> > for FC2. It will still be possible to install with it on, and development
> > work on it will continue, but it's not ready for prime time.
> 
> It is important to separate mechanism from policy.
> 
> At this point the mechanism is in good shape and policy is evolving.
> 
> Since policy is one of the most complex and difficult aspects
> it does make sense.  Management of policy may require changes to
> mechanism if solutions in rpm and other tools can not be constructed.
> 
> The current policy efforts are building a 'convenient' baseline policy
> that does not impose too large a learning curve.  This is the hard
> part and many compromises are being made at this time.  It is the
> large learning curve that will keep the default 'off'.  
> 
> Perhaps SELinux is ready but the prime time audience is not ;-)
> 
> To me the most troubling efforts are the interactions with "sudo" use,
> pam and "consolehelper" style historic solutions for administration
> and security.
> 
> One example of this is that there is currently no 1:1 mapping of
> policy and "consolehelper" links.  These historic tasks require
> elevated permissions and constitute lots of risks.  A policy to allow
> these "consolehelper" helper tools to continue running as they have in
> the past is not good security science.  The same is true for the pam
> controls related to them.
> 
> "sudo" is a more difficult task than the "consolehelper" pile of
> actions.  There is no way to generate a list of activities to write
> policy for.  
> 
> A find can locate all the links to "consolehelper" as will an
> inspection of the 90 some activities in /etc/pam.d/.  Then there is
> the long list of SUID/SGID packages ...
> 
> 
> -- 
> 	T o m  M i t c h e l l 
> 	/dev/null the ultimate in secure storage.
> 
Complexity can counteract the benefits of any new security mechanism. 
If you cannot easily audit the security settings, entropy will
eventually dissolve the original, secure settings.