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 - [EMAIL PROTECTED] - 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
