Re: Looking for someone to take over.

[davej@suse.de]

On Tue, 17 Oct 2000, Bryan Paxton wrote:

> I've put this off long enough, and instead of stamping this project as a dead 
> beast, I'm querying as to whether there is anyone out there who like to take 
> over. 
> Your duties would be nothing but taking over as list owner(for this mailing 
> list), help developers manage projects, set goals, etc.......

I think this project had good intentions, which were unfortunatly
satisfied through existing lists/channels.

Members of the security-audit list for example occasionally audit parts of
the kernel and either report to their own list, or to linux-kernel.

I'd like this list to remain, but only if someone actually intends to use
it for the purpose it was originally set up for, and not have it turn into
a list for "Wouldn't it be cool if we had xxx feature".

A lot of people seemed to have missed the point that the idea was not to
add _anything_ to the kernel, but to go through checking what we had
already, making lists of routines that don't check their input conditions
properly, routines that sleep and checking that nothing calls them with
a lock held etc etc..

Other ideas:
 - The sorts of things the Stanford students who posted to Linux Kernel a
   few months ago. Their tests showed up a _lot_ of places we do bad
   things. If someone would be prepared to take those results and just
   confirm that they're still true for the latest kernel, it would be a
   good start.
 - Someone even submitted lclint outputs to l-k once which turned up a few
   previously unnoticed bugs.
 - Tytso's TODO list still shows a lot of areas that could be classed as
   auditting.
 - The sort of things that Arnaldo Carvalho de Melo has been posting
   umpteen patches to l-k. Mostly things like updating drivers
   to use newer interfaces. The kernel is still carrying a lot of old
   backage because of this. And remember, if we kill off the old
   interface, that's less code that needs auditting.

There's no shortage of things that need checking.

A lot of this stuff really isn't rocket science, it's about finding easily
overlooked things, places where interfaces have changed and callers
haven't been updated for example. It shouldn't put people off that they
haven't had any of their code accepted for kernel inclusion, or that they
don't fully understand everything (or even much of it at all).

A lot of newcomers seem overwhelmed by the number of knowledgable people
on l-k, and are put off from posting for fear of being wrong, and have a
few thousand people notice. But people make mistakes, don't be put off.
If you find something that "just doesn't look right", it's better to be
wrong, and have everyone know that piece of code is right (and now
audited) than leave something which could be incorrect go potentially
unnoticed.

The only difficulty this projects faces is organisation.
I don't think Bryan did a bad job. How should this be organised ?
Have a list of files and hope people will say "Ok, I'll take
drivers/blah.c and audit it" ? Personally I don't think that's the right
approach. We need >1 pair of eyes looking over code, and therefore more
than one person could be auditting 1 piece of code at a time.

When do we mark something as 'auditted' ?
This is the tough one. Without a set of criteria for each auditting
operation, this will never be marked as 'auditted'.
Criteria could include the things as mentioned above.
- Validates input conditions.
- Possible race condition.
- Possible buffer overflow.
- Sleeps with locks held.
- Syntactical C errors.
etc, etc..

Additional criteria could be added as needed for special cases..
"Makes bad assumption that blah==1" etc..

Only when all conditions are "ok" then the file is marked as "auditted".

Upon release of a new kernel patch which changes that file, its
"auditted" mark is removed, and the tests should be redone.
This could be done using a script that clears any set "auditted
flags" from the patched files upon application of a kernel patch.

With the goals of this project reconfirmed, maybe someone will show some
interest ??

regards,

Davej.

-- 
| Dave Jones <davej@suse.de>  http://www.suse.de/~davej
| SuSE Labs


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