Date: Mon, 04 Dec 2000 15:50:20 -0600 From: Aaron Grothe <grothe@earthlink.net> To: kernel-audit@humbolt.nl.linux.org Subject: LKAP: A Manifesto for a Secure Linux Kernel Audit Hi, My name is Aaron Grothe. I've talked to Bryan and I'll be taking over the LKAP project for a while. I'm planning on taking a slightly different tack, and will try to layout some more ground rules to narrow the focus of LKAP. Focus Kernel version: The goal of the project is currently the 2.4 kernel series. If there is enough interest we could start a 2.2 version of the project. We'll try to keep in sync as much as possible with the current release of the kernel. Tools: We will put together a list of the best tools and work on getting more metrics of the Linux kernel. This will help us better focus our efforts. Documentation: We will also need to put together some documentation such as how to do an audit, how LKAP works, and so on. LKAP Homepage updates (To Be Done) Creating a couple of new mailing lists, such as review-announce, review-comments and so on. A browsable version of the kernel source code tree which will be updated every time a new kernel version comes out. Homepage will have a summary of the current source code tree, number of lclint warnings, cyclomatic complexity, and the rest of the metrics. Every file in the browsable kernel source code tree will have a couple of additional support files: * Original source code file * Source code file with annotations * File with lclint comments inserted * Summary page for file with metrics such as cyclomatic complexity Links to the documentation that we put together. An example code audit 1. User x decides to perform a code review of file y. 2. User x posts an announcement to the review-announce mailing list 3. User x checks the file out of cvs 4. User x performs the initial review 5. User x checks the annotated file back into the cvs tree 6. User x posts an announcement to the review-finished mailing list 7. Other users will look at the annotations and make their changes and check them into the cvs tree 8. Other users send e-mail to user x saying they have also reviewed the file 9. User x, after giving a reasonable amount of time for the review (1-2 weeks?), summarizes the changes and sends them off. Tools (Static c-code analysis tools) The following are the tools I'm currently evaluating for use. Please e-mail me with any additional tools we should investigate. lclint: the GPL answer to the classic lint. LCLint has a lot of additional functionality if you are willing to put additional information into your source code. Initially though I would like to use this as just a better lint. cccc: a tool that runs the standard metrics against source code (McCabe, Halstead, and so on). hlint: Heimdall Lint (hlint), a tool developed by Heimdall Linux that performs certain basic security checks, e.g. use of gets(), and so on. It is really a glorified version of grep. We're going to open a project on sourceforge for the Heimdall Lint tool. Some of the issues I'm still trying to resolve in my head. * How to handle annotations to the source code. We need to be able to keep track of our comments with regards to the kernel and keep them in sync as new versions of the kernel come out. We also need to be able to remove comments that no longer apply. My current theory is to use a specific comment style such as /**lkap to keep them separate. * Keeping everything in sync. Running lclint and the metric tools against all the source code files will take some time so there is the possibility that the additional files could be out of date with the real version. * The community system. Is the Sourceforge system sufficient or do we need to use another tool such as OpenACS? Unofficial Official LKAP Meeting It looks like I'll probably be attending Linux World Expo in New York in January. We might be able to arrange for there to be an informal Birds of a Feather meeting somewhere. Or we could just meet at a bar and have a discussion. Plea for Help This is the standard section where every person with a project asks for volunteers. Initially, I'm just looking for feedback on the manifesto and we'll see how it evolves from there. Schedule I'm hoping to have the browsable tree and some of the documentation up by the end of the month. We can hopefully start the auditing by the end of December or sometime in January. Summary I'm really excited about the LKAP project. For additional reading I highly recommend the original mission statement for LKAP available at http://www.lkap.org/mission.html The Gartner Group said that Linux would be the most Secure Operating system by 2005. So we've got a bit of time :-) Mini-FAQ #1. Who are you? What do you want? My name is Aaron Grothe. I'm the President/CEO of a Linux startup called Heimdall Linux. What I want is to help with the LKAP project. #2. What is your background? I worked at a couple of defense contractors before starting Heimdall Linux. You can read my resume at my website http://home.earthlink.net/~grothe #3. What is Bryan's role in this? Bryan and I have discussed this a bit. I'm laying out some guidelines for the future and will be trying to set some goals for LKAP for the future. I'm theoretically in charge of LKAP. Bryan will be helping with LKAP as time permits. #4. You talk a lot about tools. Why? The kernel is huge. We should use whatever tools are available to help us with the code reviews. One of the reasons for using tools is to help us prioritize. #5. What about the 2.2 kernel, the 2.0 kernel, the 1.2 kernel? My goal for LKAP is the 2.4 kernel. I have no objection to someone taking the tools and using them to perform an audit of another kernel version. Kernel-audit: discussion list for security and the linux kernel Archive: http://mail.nl.linux.org/kernel-audit/