Fwd: Re: where to start?

[Bryan Paxton <evil7@bellsouth.net>]

I agree with everything that you have posted.
revising on my previous post:
as I stated I think the first place to look would be in fs/ 
Not only could the coders do this, but the stress testers as well, via
exploits. 

Maybe dig up an old knfsd exploit againt the kernel it was written for,
see how the exploit worked/works. Then compare the code to the current
nfs src code in the kernel. 

> 
> Bugs of category 1) and 3) could be found by non-programmers
> too, by simply stressing the machine heavily until a bug is
> hit. Typical "overload tests" and crashme could be of help in
> this.

See above

> 
> Category 2), though, will require people to take a look at the
> code and actually audit code paths in the kernel. This will be
> more difficult work, but more fun for some of us. In the process
> of looking for category 2) bugs, we'll probably also uncover
> some bugs of category 4) ... 
> 

This is the tough part. What I propose is section by section of the
kernel. Lets look at some of the old kernels and their bugs and once
again compare it to current src code. Find bugs... improve the code. 
And yes I again I propose that this 'section by section' idea be
started in fs/  


> I guess some of the first steps we could take are:
> - collecting some programs and test scripts to look for
>   1) and 3) bugs .. and to make it easy for non-programmers
>   to setup their box as stress-test machine
> - identify "suspect" areas of the kernel that should be
>   looked at in more detail
> 
Some places where you can get old scripts and exploits:
rootshell.com, packetstorm.securify.com,  and securityfocus.com

Don't take any exploit code or text for granted. It all matters in the
improvement of the kernel

Final words:
Though I do suggest a 'section by section' this is only a sugestion...
If you feel you're better in mm/ then by all means go for it.
And always remember to express yourself freely on this list : )

Aside from fs/ 
Why don't we start in mm/ as I see this as a critical area of security
audit. Nothing worse than getting buffer overflowed and having a
production server go down that over 10,000 people rely on.

But how would we get started on this ?

Bryan Paxton

"How should I know if it works? That's what beta testers are for. I
          only coded it."
 -- Linus Torvalds.



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/