From owner-freebsd-current Tue Nov 23 21: 1:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id 0F64E154FE; Tue, 23 Nov 1999 21:01:22 -0800 (PST) (envelope-from kbyanc@posi.net) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from localhost (kbyanc@localhost) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with ESMTP id AAA56673; Wed, 24 Nov 1999 00:01:02 -0500 (EST) Date: Wed, 24 Nov 1999 00:01:02 -0500 (EST) From: Kelly Yancey X-Sender: kbyanc@kronos.alcnet.com To: Gerald Abshez Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: FreeBSD security auditing project. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Nov 1999, Kelly Yancey wrote: > > I think it would be useful to identify "unsafe" functions, so that > > anyone can participate in the "eyeball" portion of the game. This means > > that we need eyeballed, identified as a (potential) problem and fixed, > > as well as some other possiblities. There is a lot of code out there, > > and it would help if we could involve the non-programmers in the search. > > > > Comments? > > > > * We need to break the auditing process into managable work units. Specifically, I think Kris was right on the money in defining the resolution to be at the function, as opposed to file, level. Individual functions can be identified as unsafe, suspect, or as scutinized and believed to be safe. Individuals are welcome to analyze an entire file, but the status should be recorded per-function. This has the added benefit that commits which change only 1 function in a file, can reset just the confidence level of the function effected, rather than the entire file. That should reduce the amount of duplicated effort since functions which have been scrutinized and deemed safe don't require the same level of scrutiny again should some other function in the file change. > > * We need to note when a commit affects code that was believed to have > previously been secure (so that it may be audited again). This is an extension of the previous point. The on-line tool (whatever form it takes) would have to track commits and reset the confidence flag for any functions that changed. It would be ideal to reset a function's confidence rating whenever it has changed, except when the change was to make it more secure. But of course, this is impractical. The compromise would probably have to be just to always reset the rating to "suspect" and let anyone who commits a security-related fix reset the rating themself. > > * We should indicate what parts of the code have been audited without > discouraging others from double-checking if they like. Continuing the previous thought: we could allow people to attach their assessment to function records in the database. So that if one reviewer "eyeballs" the code and believes it to be safe, they can say so, and it is recorded along with the current version of the file the function is in, and the date of the assessment. This gives us 4 rewards: First, that everyone can see which functions have been reviewed. Second, that if commits make a function unsafe, it would be trivial to identify the last safe version of the file and thus the function. Third, it allows multiple people to review the same function, knowing that someone else has already reviewed it. If I eyeball a function and suspect it to be unsafe, I can attach my "suspect" assessment to the function. Someone looking for functions to investigate could query all of the functions whose most recent assessment was "suspect" (or worse, "unsafe", see last point below). Finally, it requires no effort on the part of the cvs-meisters (ie. no messing with CVS tags); all auditing information is stored outside of the CVS repo. > > * We would like to be able to identify and integrate security fixes > already made by OpenBSD or NetBSD easily. The main obstacle I see here is the divergence in the code bases. Specifically, functions have slightly different names in many places, the file hierarchies are organized differently, and god-knows what else. The only way I can figure to begin to automate the process of integrating fixes from other *BSDs would be to build a mapping relationship for functions and files between their source trees and ours. That may well take as much effort as the audit itself :) I think the only reasonable way to get the fixes merged into our source is for hackers to do it by hand. That isn't to say that we couldn't provide a central place for security-conscious hackers to view security-related commits to other BSD's source trees, past and present. I suspect grepping for things like "overflow" in commit logs for the other BSDs would go a long way in separating the wheat from the chaffe. We can help people find out about potential bugs, but I just can't see how the hand-holding could extend any further. > > * We would like to flag programs as suspect/insecure when they are the > subject of bugtraq reports. The big trick here is that bugtraq reports aren't always nice enough to point us to the specific file/function that is causing the bug :). Either someone has to be responsible for manually identifying the offending files and/or functions as "unsafe" or else we have to take the same policy as with merging fixes from the other BSDs and just provide the information for the more intelligent chair-to-keyboard interface to figure out. That aside, I have used 3 confidence levels thoughout this message for indentifying the audit status of files: "unsafe," "suspect," and "safe". These are just examples, and could easily be replaced with more fine-grained terms or even a numberic confidence rating system (say a percentage, for example). In any event, I hope the idea is clear. Now, all this theory stuff is fine and dandy, but what about the code? I'de be glad to starting implementation this upcoming Monday (I'm going to have a couple of weeks where I can spend the majority of the day coding on FreeBSD-stuff). I'm looking forward to feedback, Kelly -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message