This is a mission statement for a project under way and ready to get going.
The Linux Kernel Auditing Project (LKAP).
The purpose of this project is self-explanatory. It's an attempt to audit the
Linux kernel for any security vulnerabilities and/or holes and/or possible
vulnerabilities and/or possible holes, and of course without adding more bugs or
drawbacks to the existing kernels. The suggested kernels to be audited are
2.0.x kernel series , 2.2.x kernel series, and the 2.3.x/2.4.x kernel series.
The group and it's work shall be dealt and worked with via a mailing list.
How to subscribe:
echo subscribe kernel-audit | mail majordomo@nl.Linux.org
I feel that this project should have been done a long time ago, not to imply that
the Linux kernel is insecure, but a case in which this project would've helped
would be the setuid() hole found on June 7
which affected all 2.2.x kernels. This bug was patched in a matter of hours
(isn't open source great!). But here's the point, the flaw/function/hole
should _NOT_ have existed in the first place. Which is where this project comes
into place.
There's a few things that differ from this project compared to a few others
that are similar.
1) To audit the kernel source code without affecting/breaking/disrupting any other
part of the kernel. These will not be additional patches you can downloads
(add-ons). This auditing is dealing with the current code in the source, not adding
or implementing new functions.
2) To educate kernel developers/hackers on how to securely write code. It is
my hopes that kernel developers/hackers new and old will subscribe and post to
this mailing list with questions and share information,
and to simply get help with their code(e.g.: Could this function() cause a
possible security hole or lead to an exploit ?"), this is the true power of
open source and GNU/Linux
3) To be ahead of the game... A perfect example of this are certain proprietary
Operating System developers who sit around and wait for a security bug to come to them
and not go to find the bug themselves. Of course this needs no explanation as to why this
never works. I feel that kernel developers/hackers are down to earth and pretty
logical people and realize that Linux is _NOT_ perfect, that a lot of the code
they write, submit, and gets plugged into the kernel is not flawless and more
than likely could be improved for security reasons.
4) To provide an operating system to the public. I want to see a Linux where
the sysadmin doesn't have to watch his back all the time in fear of say some
new knfsd exploit or a way to fork()bomb his/her router via a simple mistake
in buffer.c
5) To provide a safe Linux to the end-user.. Linux is slowly but surely becoming
a choice for the desktop user. Most of these users are walking into Linux with
no knowledge of what potential dangers lie at their finger tips and in their
hard drive. Linux has proven to be one of the most secure operating systems, but
I feel as Linux becomes more popular with the general public this will change,
that more kernel security holes and exploits will arise from nowhere and give
us a very unpleasant reality check.
And at last, this will be no easy project, security auditing never is.
It takes man power, skill, and just plain aching time. But I believe if the
community gets together on this one, nothing will stop us and Linux will
go on to become the #1 security-wise operating system to this date.
Sincerely
Bryan Paxton
How to subscribe:
echo subscribe kernel-audit | mail majordomo@nl.Linux.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 09 2000 - 17:56:50 EDT