[Security_sig] 10/14 Conf. call minutes

[Ed Reed]

Thank you, Stephen for your cogent and civil reply.  Your postings
here have been welcome and very helpful.

4 spaces.

;-)

As for the security professionals - there are many, you are 
certainly one, as are others on this distinguished list.  But so,
too, is our consituency of practical, in-the-trenchs system
administrators who, like it or not, serve double duty in far
too many IT shops as both the designers and maintainers of
security policy as it is actually applied - firewall filters,
login policies, access control permissions, application
installations and reconfigurations, password expiration
policies, and name and web service load balancing.  

How do we help those folks, particularly the ones who earnestly
are trying to "do the right thing", and make it easier to
stay within the lines?  As vendors, and as industry technology
providers, we've got to be thinking about the human part of
this equation.

There are tens of thousands of folks who have paid money,
attended classes, taken tests and gotten certified as having
a certain level of competancy with regard to system administration
which does include configuration and monitoring of security
"stuff".  It's possible that a disproportionate portion of that
training goes towards dealing with one vendor or another DAC
access control system.  

We, or at least I (and I think you do, too) want to find a way
to raise their sights and apply their skills to managing systems
that enjoy integrity protections, mandatory policy enforcement
of least privileges, and that enable organizations to split
administrative duties among multiple different employees when
circumstances and operational policies require it.

If we're agreed on that goal, we're working in the same direction,
and that's cause for celebration all by itself.  It's a first
step towards figuring out how much is enough, what is too
much, and how to phase a series of transitions (that will take
far longer than one product delivery cycle to "take" in the
market place) that move us in the right direction.

It takes 10 years for new, good ideas to become widely
accepted and adopted in the market place.  Consider:

PCs (~1982-1992)
TCP/IP (~1984-1994)
LDAP (~1995-2002)

The WWW launched as the result of the availability of TCP/IP.
But it's taken much of the time since 1994 to get to the point
that businesses no longer think about whether to use the Internet,
but rather what to do when it's not available.

It will take 10 years for a root-less administrative model to
take root (sorry, couldn't resist) and become accepted as the
natural default security policy for Linux.  Windows might 
actually get there sooner, as they're already headed down the
RBAC path.

Why 10 years?  It's based on the 18 month product development
cycle:

Year 0) new idea - can't get anyone to listen to it, because they're
all working to complete their deliverables for the next release
due next quarter - 

Year 1.5) new idea is on the list of "desireables", but below the
line of prioritized features promised last time and not delivered.

Year 3) new idea has been talked up and is in the queue, this time
above the line for consideration - it makes it.  The application
developers will believe it when they see it.

Year 4.5) new idea is designed and developed, if it's not too
much of a stretch - new ideas are usually introduced in 
infrastructure, where they become prerequisites for application
and service development and delivery.  Alpha and Beta test
cycles demonstrate, once again, how important documentation and
adequate sales collateral are.  Industry analysts see it but think
it's something else alltogether.

Year 6) new idea comes to market, giving customers and analysts
their first real look at it.  They take it into their labs
to consider it for use if it seems to work.  Now, finally,
application groups can begin consuming it, and they stretch it
all out of shape as they apply it to places and solutions never
anticipated by the original designers.  Customers are worse, 
still, because they still think the thing does what the
marketing collateral said it would do 2 years ago.

Year 7.5) after the 1st release (no one ever deploys an even
numbered version), analysts agree it's time to seriously
consider this thing.  Early adopters who played with it when
it came to market push it into production, where the first
scaling issues are surfaced.  Urgent demands for feature
requests follow.  Some 30% of applications and services
from the company where the new idea came from are using it.

Year 9) new idea is stable, scaleable, recognized in the 
in the industry as a great idea and is beginning to attract
immataters.  Other infrastructure companies are doing their
thing with slightly incompatible versions of the original
new idea.  Application adoption approaches 70% in the
community where it originated.  Demands for a new GUI
are first heard, as the language/object model/protocol
standard de jure has moved on since the original design,
and every one agrees this thing is hopelessly out of
date and nearly unsupportable.

Year 10.5) The Open Group announces an interoperability
test suite development effort.  A brand for the 
interoperability testing is proudly announced.

But, that's just my perspective.

Ed
 
 
>>>Stephen Smalley <sds at epoch.ncsc.mil> 10/22/04 12:02 pm >>> 
On Wed, 2004-10-20 at 20:49, Ed Reed wrote: 
>The huge disconnect I've had with the SELinux project has been, as 
>we've discussed, Stephen, the awkward reality that the benefit you 
>offer (fine-grained MAC via TE), does not map to the benefit that is 
>available from sales to agencies coming under MLS policy acquisition 
>guidelines.  At least, not that has been shown to be the case, yet. 
> 
>In other words - there's a ready market for MLS solutions, and 'til 
>recently, no one working on them in the SELinux space.  
> 
>I'm grateful and excited to know that is now changing.  
 
Thanks for your comments.  The reason that no one has worked on MLS 
solutions based on SELinux until recently is that MLS is not a 
motivating example for getting MAC technology into mainstream operating 
systems.  With SELinux, we provided an architecture and mechanism that 
was capable of supporting MLS requirements while focusing initially on 
security models that were viewed as useful not only to MLS systems but 
also to a wider user base.  And, as you say, someone is now working on a

MLS solution based on SELinux.  What other Linux MAC solution can 
support this range of security requirements? 
   
>Whether MLS or TE presents a better security policy framework 
>is the subject for another discussion. 
 
They don't have to exclude one another; TE was originally developed to 
fill in the gaps of MLS systems, not to replace MLS.  TE is more general

and better suited to providing least privilege, integrity, and 
separation of duty than MLS.  In any event, the SELinux framework can 
support them both. 
 
>Whether TE is ready for specification as an industry agreed, concensus 
>driven security framework is, however, an appropriate topic for this 
>group.  Until it has had the chance to be reviewed, accepted, and 
>adopted by the security professionals in the industry, it seems
premature 
>to put it forward for widespread deployment. 
 
Are you applying this same criteria to every security solution that this

group will consider putting forward?  Does LIDS meet this criteria?  How

about SubDomain?  Who exactly are these security professionals in the 
industry?  When do they agree on anything?  If your group is only going 
to follow and never lead, what is your purpose? 
 
>What is concensus today is that: 
> 
>1) root has too many privileges for all the various administrators who 
>have need to use some of them to do their limited jobs;  This, by the 
>way is ONLY recognized to be generally true in large enterprise, raised

>floor high availability data center deployments - there's much less 
>concensus for other scenarios; and 
>2) it's hard to get people to change 
> 
>Tackling those two realities will break a lot of ice, and will pave the
way 
>for much more nuanced security policies in the future. 
 
How is this counter to deploying SELinux, which can support #1 without 
imposing the complexity you fear via alternative policy configurations? 
 
>As it stands now, you can't even get people to agree whether 
>three spaces or four is the right translation of the ascii tab
character 
>in their favorite text editor - the systems management console of 
>choice by a lot of the hard-liners. 
 
8 spaces. 
 
>I expect that the next couple of years in the commercial software 
>deployment space will deal, for the first time, with wide spread 
>adoption and experimentation with MAC of all varieties.  The 
>community has new tools, enabled by the invaluable work done 
>by the SELinux team, to explore these areas, and to experiment 
>with what does and doesn't work.  We're likely to see every 
>mistake of the past 30 years recreated, and hopefully a whole 
>batch of new ones. 
> 
>But if we're lucky, there'll be some that put 2 and 2 together 
>to create something unexpected and really useful.  Simply 
>because we'll have more eyes working the problem, and 
>more perspective on what's worked in the past and what's 
>not. 
 
That way lies madness, and much wasted time and resources.  You can 
deploy a sound framework and mechanism now, and play with all different 
flavors of policy configurations if you like, but leave radical 
experimentation with MAC modules to researchers, please, it has no place

in production deployment. 
 
>Think of me as working on the same problem, but just in 
>a different area, that I really hope will converge with your 
>own efforts - over the next 30 years or so. 
 
30 years?  RHEL4 systems will be shipping with SELinux early next year. 
TCS' press release indicated that they will be offering their Trusted 
Linux platform based on SELinux in spring 2005.   As above, 30 year 
horizon might be fine for your researchers, but not what I would expect 
from this group. 
 
>How do we get these chuckleheads to realize they 
>not only need MAC, but that they actually want it? 
 
By applying resources to address their useability concerns, so that the 
security benefits can sell themselves without that obstacle. 
 
-- 
Stephen Smalley <sds at epoch.ncsc.mil> 
National Security Agency