[cgl_discussion] Buffer overflow

[Mika Kukkonen]

On Tue, 2003-04-22 at 17:24, Bill Roy wrote:
> Hello CGLers:
> 
> My first post as an interested bystander who has been monitoring for a
> while.

Always nice to see new names on email headers ;-)

> I fully agree with the technical merit of this suggestion to raise the
> intrinsic security baseline of Linux distributions for operators.
> Non-executable stack should have been part of every baseline architecture
> for decades.

Well, as has been raised before, the major hurdle for acceptance of any
security feature lies on what is it performance impact: if it very small
like the LSM hooks that have now been added to mainline, it has a
change. But otherwise (like in case of http://www.nsa.gov/selinux/),
the community just does not seem to be willing to accept loss of
performance.

So for CGL we have this dual definition of mainline, so that instead
of community adoption we can aim for distro adoption. But to be
truthful, those two go often hand in hand (i.e. it is hard to get
distros pick something up that has no community support).

> But, I have a question; I hope you will forgive me if this is a stupid one.
> Where would CGL get market validation for making an item like this one
> mandatory?  I have seen several completely reasonable technical points
> raised in this thread, but no input from, for example, operators or SI's
> responsible for deploying and maintaining these service complexes to
> validate that this represents an item that will remove an obstacle to
> deployment of Linux in the operator.  Surely, there must be some
> counterbalance of market requirements against technical goodness in arriving
> at requirements sets for CGL.

Yes, we have this thing called CGL Marketing group (Doug Kolb on CC of
this email is the chair of that) that composes of the member companies
marketing people, including people from NEPs and distros. And their job
is to make sure our features meet the market requirements of _their_
customers.

While our marketing group is nowadays already thinking about version 3
specs, they also keep an eye on our specs through the internal work
process (to be short, every document that goes out of CGL needs to
be ratified by the CGL Steering group).

> I have a similar observation for some of the mandatory 2.0 features in the
> Security section, for example the ones regarding secure syslog.  What
> deployment would not already have syslog on a secure management network?

You would be surprised :-) Let me ask you a counter-question: how many
distros today include secure syslog as default in their distro?

> So, to restate my question: I see great technical discussions going on here;
> where does market validation come from?

>From the CGL Marketing group, and also any feedback through this mailing
list is appreciated.

> I sit on the Board of OMA and SyncML; we also struggle with this question
> all the time.  I'm keenly interested in your thoughts on the process in CGL.

Ah, I feel your pain. I think the advantage CGL has is that we are very
tightly focused (i.e. on Linux in carrier-grade environment) and have
members that will be using our specification directly in their business,
and so have a keen interest to see that our specs address the real
world.

It also helps a lot that when listing requirements, we also look at what is
available out there as existing Open Source projects. If there is no project
addressing a certain feature, that can be an indication that maybe this 
feature is not so important after all.

To be truthfull, the interaction between tech people and marketing group is
not so clear cut and well oiled machine, but we do have a process in place.

Thanks for your interest.

--MiKu