[LWN Logo]
[Timeline]
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/