Look at OpenBSD [LWN.net]

Look at OpenBSD

Posted Feb 5, 2004 11:16 UTC (Thu) by Cato (subscriber, #7643)
Parent article: Needed: code auditors

It's clear that OpenBSD is one of the more successful code auditing efforts - they continually audit code for all sorts of bugs, not just security, and manage to close security holes in the process. It would be good to examine how they've created this culture of security auditing and figure out whether and how this could be re-created around Linux and other open source software.

(Log in to post comments)

Look at OpenBSD

Posted Feb 5, 2004 12:03 UTC (Thu) by slowjoe (guest, #18834) [Link]

Yes, OpenBSD lead the field regarding code auditing.

Unfortunately, they don't seem to document the classes of bugs that they search for, and at trade shows, I've asked them about this...they aren't helpful in generalising. I just remember that Theo had apparently moved from worrying about printf bugs to bad handling of file descriptors.

Has anyone documented the OpenBSD bug classes?

Look at OpenBSD

Posted Feb 5, 2004 16:25 UTC (Thu) by ncm (subscriber, #165) [Link]

They very deliberately refuse to classify bugs according to whether they affect security. That is one of their better insights, because any bug may be a security hole, and it is very difficult, in general, to distinguish. Put another way, any such classification will have a very large fraction of erroneous assignments.

That's not to say they couldn't classify bugs along other axes. However, taking all bugs seriously, and minimizing the overhead involved in reporting and fixing them, are key enablers of their practice. Demanding classifications and other statistically useful overhead might backfire.

Look at OpenBSD

Posted Feb 5, 2004 17:30 UTC (Thu) by thoffman (subscriber, #3063) [Link]

It should be possible (and educational) to figure out how they do it just by looking at how their CVS tree has evolved over time.

And reading their mailing lists, of course. But even if they discuss security issues on closed lists, the code is open and someone who took the time could look at all the patches they make, classify them into bug fixes and features, and then look at all the bug fixes and start creating a "taxonomy" of bug fixes.

A well documented collection like that would be a very useful tool to teach other developers to audit code. Maybe some university prof out there will have her students put together documentation like that, and then audit some Linux code for the same sorts of problems?

Look at OpenBSD

Posted Feb 6, 2004 8:13 UTC (Fri) by Cato (subscriber, #7643) [Link]

I was talking about the culture of security auditing, not how they classify bugs etc - reproducing this will mean talking to people not just looking at CVS and email logs.