General Information

Overview

In light of our recent (and still ongoing) security concerns, it has become rather obvious that nothing less than a rigorous and comprehensive security review of the FreeBSD source tree will enable us to really have much confidence in the security of our operating system, an OS that many have come increasingly to rely upon and must be made more than reasonably secure if they are to continue to be able to do so.

The sheer amount of legacy code & code from outside sources in FreeBSD also makes it especially easy for security holes to go unnoticed until it's rather too late, and no truly large-scale attempt has been made up to this point to really go through the codebase with a specific focus on security issues, that being a rather big project and most FreeBSD developers being more than busy enough elsewhere. This situation must now change, however, if we are to remain the kind of operating system that people can continue to rely upon as the Internet continues to grow and (I suspect) become an ever-more hostile environment for improperly protected systems. Proper security is something of a cooperative arrangement between the local administrator and the OS vendor, and this "OS vendor" needs to do its part.

The core team's first step in becoming more serious about security was to bring the project's security officer, Guido van Rooij, into the team so that one of the "voices at the table" would have security as his primary mandate and representation in all the important security mailing lists external to the FreeBSD Project. He will also keep the rest of us in core much more aware of security concerns as they arise, hopefully not to be taken quite so by surprise as we have a few times in the past.

Our second step will be this audit, an attempt to methodically go through every line of source in FreeBSD looking for obvious buffer overflows (sprintf()/strcpy() vs snprintf()/strncpy() and so on), less obvious security holes, instances of insufficiently defensive coding, amusing comment strings to forward to freebsd-chat, whatever we run across.

Using the modules database as an outline, we will split the source tree into more manageable pieces, keeping a sign-up sheet in a prominent place so that people can see which modules are covered and which are not. A carefully selected team of individuals is now also being formed, that team being composed of "auditors" and "reviewers" (most members of the team being both). An auditor has principle responsibility, which may be shared with another auditor, for actually going through the code and looking for security holes and/or bugs. Once a reasonable pile of diffs have been accumulated, assuming that any problems were found, they are send to one or more reviewers who are responsible for giving the changes another once-over and, if the auditor does not have commit privileges, to actually commit the changes when & if they're deemed acceptable.

Requirements:

In order to be an auditor, you should either have commit privileges on freefall.freebsd.org or an arrangement with another auditor/reviewer who does. You should also be running or have immediate access to FreeBSD-current sources since all of our changes will be made relative to that branch and then brought back (as necessary) into the 2.1 and 2.2 branches.

What to look for and what the general rules to follow are is sufficiently complex that I have turned it into a FreeBSD Security Guide. Please read this now if you haven't already. Another excellent document is the Secure Programming Checklist, available from AUSCERT.

Sign-Up sheet:

Here is the sign-up sheet as it sits so far. This is *very* skeletal at this stage, given that we've just now started, and as people indicate which module(s) they're willing to either audit or review, we'll fill it in. If this tabular format also becomes unwieldy as it fills up, we can change it or put it on a web page or something. :) I've left some sample entries open just as place-holders, and they in no way imply that someone has to be willing to pick up pieces that large.

Anything in the modules database represents a potential auditing target - from ones as small as "cat" to ones as large as "lib", the most important being that people bite off pieces no larger than they think they can chew. If you take 15 things onto your plate and deal with only 5, you're not doing anyone any favors since the other auditors will be assuming that the other 10 items are handled!

Module	Auditor(s)	Reviewer(s)	Status
lib	pst	jkh,dg,gvr,imp	Open
libc	ee	open	Open
libdisk	open	phk	Open
libexec	imp,crh,ee	open	Open
telnetd	ac,dn	imp	Open
bin	ac,gvr,ee	imp,md	Open
sbin	taob,imp,ee	md	Open
usr.sbin	imp,rd,marc,ee	md	Open
usr.bin	rb,rjk,rd,jha,ee	md	Open
eBones	mrvm	open	Open
secure	mrvm	open	Open
games	xaa,ab,ee	open	Open
lkm	open	open	Open
release	open	open	Open
contrib	cg	open	Open

Auditor/Reviewer keys

This is the list of people who have volunteered to participate as auditors or reviewers in this process. They may also be reached collectively by sending mail to the auditors@FreeBSD.org alias at times when it is appropriate to send mail to all auditors. If you wish to reach just the auditors & reviewers for a specific category, say for example usr.sbin, then you would send mail to audit-usr.sbin.

* = Has CVS commit privileges.