Re: Some suggestions.

[Chris and Tony <chriton@geocities.com>]

>
> >
> > Someone mentioned splitting the kernel into subsystems and auditing them
> > in turn. While this would catch stuff like potential buffer overflows
> > incomplete/lacking parameter validations
>
> I honestly think we should at least at first, concentrate on security related
> issue only.  most of the kernel bugs have very little if at all relation to
> security.
>
> Well, if a bug has caused the kernel to crash,. you can call it DoS (if a
> user can reproduce it).
>
> How many user-controllable buffer overruns do you know have been found
> or not yet found in the kernel?
>
> > it won't catch design bugs and
> > thinkos in the interaction of the subsystems.
> >
>
> I really think these are for the developers to find, don't you agree?

Not at all. Assuming this sort of audit really is necessary to consider the
security ramifications, once we have found a problem, we should fix it or at
_LEAST_ make the maintainer aware of it if it's not going to affect security.

I certainly would buy the assumption that this sort of in-depth audit _IS_
necessary.


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