[Security_sig] 10/14 Conf. call minutes

Ed Reed ereed at novell.com
Wed Oct 20 17:49:57 PDT 2004

comments below 

>>> Stephen Smalley <sds at epoch.ncsc.mil> 10/19/2004 3:53:51 PM >>>
On Tue, 2004-10-19 at 13:26, Gé Weijers wrote:
> As I am one of the people who have expressed that sentiment I feel the 
> need to explain myself :-)

 - me too!  My, what a lively debate has been stirred up! 

> None of the above is impossible, but it needs to be done. Given the 
> deafening silence we usually get when we ask security-related questions 
> I doubt that people will be standing in line to work on this. I wish it 
> were different.

Standing in line?   No.  But I believe that there are people in this
group who could apply more resources to these problems, and AFAIK, they
aren't doing so.

 - err, might that be me? ;-)

We're talking here about costs and benefits of security investments.

For vendors, there's the benefit of being able to sell something.

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.  

Whether MLS or TE presents a better security policy framework
is the subject for another discussion.

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.

When it is the concensus agreement, it will no doubt already have won 
(wow, future perfect tense?).

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.

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.

Policy must be understandable by the folks who work with it, who use
it, who have to change it as part of their daily administrative duties,
and by developers who will produce products and projects that have
to fit into things already in place.  Until then, it needs interpretors,
who all too often become shaman, who may or may not really know
what they or their policies are doing.

That's not, yet, assurance.  It's progress.  But it's not there, yet.

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

I'm working hard to foster that new round of exploration and
innovation, because the insights that come out of that might
just help drive the community to concensus as to what kind
of policy works best in the half-dozen or so "typical"
deployment scenarios we all face day-after-day.

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.

Welcome to the list - your perspective and insight are
very much needed.

Now - back to the main issue:

How do we get these chuckleheads to realize they
not only need MAC, but that they actually want it?



More information about the security_sig mailing list