[cgl_discussion] Re: Buffer overflow

Makan Pourzandi (LMC) Makan.Pourzandi at ericsson.ca
Mon Apr 28 14:00:53 PDT 2003


> -----Original Message-----
> From: Greg KH [mailto:greg at kroah.com]
> Sent: Monday, April 28, 2003 3:27 PM
> To: Makan Pourzandi (LMC)
> Cc: 'Mika Kukkonen'; cgl_discussion at lists.osdl.org; Campadello Stefano
> Subject: Re: [cgl_discussion] Re: Buffer overflow
> 
> 
> On Mon, Apr 28, 2003 at 03:06:26PM -0400, Makan Pourzandi (LMC) wrote:
> > Hi all, 
> > 
> > There are already several valid open source projects 
> regarding buffer
> > overflow, also given the necessity of protecting the system against
> > the numerous buffer overflows. I propose considering the requirement
> > for CGL 2.0, it means as for section 6 (For example, Pax mechanisms
> > are already part of trusted debian, openbsd (ok, not linux, I know
> > :-)), and several others .... ).   
> 
> Um, I think the fact that you admit the features are not part of Linux
> today, should not place such a high priority or maturity 
> level of these
> features.  Fact is, they all have their drawbacks and reasons for not
> being mainline:
> 

Well, you have a good point. We know that it'll take some time before these changes get accepted/matured to the linux main line. therefore, there is no valid reason to put them for cgl sec req 2.0. I'll put them at Cgl 3.0, which will bring us to a year in the future. 

> > 1.	PaX kernel Patch: "The goal of the PaX project is to research
> > various defense mechanisms against the exploitation of software bugs
> > that give an attacker arbitrary read/write access to the attacked
> > task's address space. This class of bugs contains among 
> others various
> > forms of buffer overflow bugs (be they stack or heap based), user
> > supplied format string bugs, etc."  
> (http://pageexec.virtualave.net/ )
> 
> This slows things down.  It also breaks existing programs 
> that currently
> ran just fine.  These are both reasons it's not more widly used.
> 

We define different levels of security for our system. The security level required for these mechanisms is level 3 (highest); at this level the highest priority  of the system is to enforce security. This means that the overhead at this level is acceptable. 

> > 2.	StackGuard is an enhancement to GCC that generates programs
> > robust against stack-smashing attacks.
> > http://www.immunix.org/stackguard.html  
> 
> This is for a _very_ old version of gcc.  One that no distro supports
> anymore.  The developers have been promising for the past two years a
> newer version against gcc-current, but have shown no working code.  So
> this really isn't a viable options.
> 

You're right. 
I remove this reference. 

> > 3.	ProPolice is an enhancement to GCC that generates programs
> > robust against stack-smashing attacks.
> > http://www.trl.ibm.com/projects/security/ssp/ 
> 
> This is better, and is what openbsd uses.  But I don't know 
> of any Linux

Anyway, Trusted Debian is not a general purpose distro, but out of curiosity, 
what about Trusted Debian? It has been released a weak or so ago, I haven't had time to test it but there is a long texte on their web site about Pax and ProPolice? Even if I can't find any place stating that they have built their packages with ProPolice. 



> distros that have tried to use this to build all of their packages and
> test with them.  The developers seem to be focusing their 
> efforts on the
> various BSDs, which is great, but can't be considered a Mature
> technology for Linux today.
> 

Agreed, see my comments above. 

> In short, please modify the priorities and maturity levels of this
> entry, if you choose to add it to the CGL spec.
> 

send a new version before the end of the day. 


> thanks,
> 
> greg k-h
> 



More information about the cgl_discussion mailing list