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.
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.
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!
To sign up for something, please send mail to jkh@FreeBSD.org.
| Module | Auditor(s) | Reviewer(s) | Status |
|---|---|---|---|
| lib | pst,ak | jkh,dg,gvr,imp | gvr |
| libc | ee | gvr | Open |
| libdisk | open | phk,gvr | Open |
| libexec | imp,crh,ee,witr | gvr | Open |
| telnetd | ac,dn | imp,gvr | Open |
| bin | ac,gvr,ee | imp,md,gvr | Open |
| sbin | taob,imp,ee,or | md,gvr | Open |
| usr.sbin | imp,rd,marc,ee,ejc,jm | md,gvr | Open |
| usr.bin | rb,rjk,rd,jha,ee,ky,bob,jm | md,gvr | Open |
| eBones | mrvm | gvr | Open |
| secure | mrvm,dc | gvr | Open |
| games | xaa,ab,ee | gvr | Open |
| lkm | dob | gvr | Open |
| release | open | gvr | Open |
| contrib | cg | gvr | Open |
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 usr.sbin for example, then you would send mail to audit-usr.sbin@FreeBSD.org.
| Key | Auditor/Reviewer Name and Email address |
|---|---|
| ab | Aaron Bornstein aaronb@j51.com |
| ac | Adrian Chadd adrian@psinet.net.au |
| ak | Adam Kubicki apk@itl.waw.pl |
| am | Albert Mietus albert@gamp.hacom.nl |
| avk | Alexander V. Kalganov top@sonic.cris.net |
| bb | Bob Bishop rb@gid.co.uk |
| bob | Bob Willcox bob@luke.pmr.com |
| btm | Brian T. Michely brianm@cmhcsys.com |
| cg | Coranth Gryphon gryphon@healer.com |
| cl | Chris Lambertus cmlambertus@ucdavis.edu |
| crh | Charles Henrich henrich@crh.cl.msu.edu |
| dc | Dan Cross tenser@spitfire.ecsel.psu.edu |
| dg* | David Greenman davidg@FreeBSD.org |
| din | Dinesh Nair dinesh@alphaque.com |
| dn | David Nugent davidn@labs.usn.blaze.net.au | -
| dob | David E. O'Brien obrien@NUXI.com | +
| dob* | David E. O'Brien obrien@FreeBSD.org |
| dz | Danny J. Zerkel dzerkel@phofarm.com |
| ee | Eivind Eklund eivind@FreeBSD.org |
| eh | Elijah Hempstone avatar@gandalf.bss.sol.net |
| eh | Ernest Hua hua@chromatic.com |
| ejc | Eric J. Chet ejc@gargoyle.bazzle.com |
| gl | Giles Lean giles@nemeton.com.au |
| gvr* | Guido van Rooij guido@FreeBSD.org |
| gw | Graham Wheeler gram@oms.co.za |
| imp* | Warner Losh imp@FreeBSD.org |
| jb | Jim Bresler jfb11@inlink.com |
| jha | John H. Aughey jha@cs.purdue.edu |
| jk | Jerry Kendall Jerry@kcis.com |
| jkh* | Jordan K. Hubbard jkh@FreeBSD.org |
| jm | Josef Moellers mollers.pad@sni.de |
| jmb* | Jonathan M. Bresler jmb@FreeBSD.org |
| joe* | Joe Greco jgreco@solaria.sol.net |
| ki | Kenneth Ingham ingham@i-pi.com |
| ky* | Kazutaka YOKOTA yokota@zodiac.mech.utsunomiya-u.ac.jp |
| marc | Marc Slemko marcs@znep.com |
| md | Matt Dillon dillon@best.net |
| mr | Mike Romaniw msr@cuc.com |
| mrvm* | Mark Murray mark@grondar.za |
| or* | Ollivier Robert roberto@keltia.freenix.fr |
| pb | Peter Blake ppb@baloo.tcp.co.uk |
| peter* | Peter Wemm peter@FreeBSD.org |
| phk* | Poul-Henning Kamp phk@FreeBSD.org |
| pst* | Paul Traina pst@FreeBSD.org |
| rb | Reinier Bezuidenhout rbezuide@oskar.nanoteq.co.za |
| rd | Rajiv Dighe rajivd@sprynet.com |
| rel | Roger Espel Llima espel@llaic.univ-bpclermont.fr |
| rjk | Richard J Kuhns rjk@grauel.com |
| rm | Robin Melville robmel@nadt.org.uk |
| rs | Robert Sexton robert@kudra.com |
| sc | Sergei Chechetkin csl@whale.sunbay.crimea.ua |
| tao | Brian Tao taob@risc.org |
| tdr | Thomas David Rivers ponds!rivers@dg-rtp.dg.com |
| witr | Robert Withrow witr@rwwa.com |
| xaa | Mark Huizer xaa@stack.nl |
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.
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.
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!
To sign up for something, please send mail to jkh@FreeBSD.org.
| Module | Auditor(s) | Reviewer(s) | Status |
|---|---|---|---|
| lib | pst,ak | jkh,dg,gvr,imp | gvr |
| libc | ee | gvr | Open |
| libdisk | open | phk,gvr | Open |
| libexec | imp,crh,ee,witr | gvr | Open |
| telnetd | ac,dn | imp,gvr | Open |
| bin | ac,gvr,ee | imp,md,gvr | Open |
| sbin | taob,imp,ee,or | md,gvr | Open |
| usr.sbin | imp,rd,marc,ee,ejc,jm | md,gvr | Open |
| usr.bin | rb,rjk,rd,jha,ee,ky,bob,jm | md,gvr | Open |
| eBones | mrvm | gvr | Open |
| secure | mrvm,dc | gvr | Open |
| games | xaa,ab,ee | gvr | Open |
| lkm | dob | gvr | Open |
| release | open | gvr | Open |
| contrib | cg | gvr | Open |
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 usr.sbin for example, then you would send mail to audit-usr.sbin@FreeBSD.org.
| Key | Auditor/Reviewer Name and Email address |
|---|---|
| ab | Aaron Bornstein aaronb@j51.com |
| ac | Adrian Chadd adrian@psinet.net.au |
| ak | Adam Kubicki apk@itl.waw.pl |
| am | Albert Mietus albert@gamp.hacom.nl |
| avk | Alexander V. Kalganov top@sonic.cris.net |
| bb | Bob Bishop rb@gid.co.uk |
| bob | Bob Willcox bob@luke.pmr.com |
| btm | Brian T. Michely brianm@cmhcsys.com |
| cg | Coranth Gryphon gryphon@healer.com |
| cl | Chris Lambertus cmlambertus@ucdavis.edu |
| crh | Charles Henrich henrich@crh.cl.msu.edu |
| dc | Dan Cross tenser@spitfire.ecsel.psu.edu |
| dg* | David Greenman davidg@FreeBSD.org |
| din | Dinesh Nair dinesh@alphaque.com |
| dn | David Nugent davidn@labs.usn.blaze.net.au | -
| dob | David E. O'Brien obrien@NUXI.com | +
| dob* | David E. O'Brien obrien@FreeBSD.org |
| dz | Danny J. Zerkel dzerkel@phofarm.com |
| ee | Eivind Eklund eivind@FreeBSD.org |
| eh | Elijah Hempstone avatar@gandalf.bss.sol.net |
| eh | Ernest Hua hua@chromatic.com |
| ejc | Eric J. Chet ejc@gargoyle.bazzle.com |
| gl | Giles Lean giles@nemeton.com.au |
| gvr* | Guido van Rooij guido@FreeBSD.org |
| gw | Graham Wheeler gram@oms.co.za |
| imp* | Warner Losh imp@FreeBSD.org |
| jb | Jim Bresler jfb11@inlink.com |
| jha | John H. Aughey jha@cs.purdue.edu |
| jk | Jerry Kendall Jerry@kcis.com |
| jkh* | Jordan K. Hubbard jkh@FreeBSD.org |
| jm | Josef Moellers mollers.pad@sni.de |
| jmb* | Jonathan M. Bresler jmb@FreeBSD.org |
| joe* | Joe Greco jgreco@solaria.sol.net |
| ki | Kenneth Ingham ingham@i-pi.com |
| ky* | Kazutaka YOKOTA yokota@zodiac.mech.utsunomiya-u.ac.jp |
| marc | Marc Slemko marcs@znep.com |
| md | Matt Dillon dillon@best.net |
| mr | Mike Romaniw msr@cuc.com |
| mrvm* | Mark Murray mark@grondar.za |
| or* | Ollivier Robert roberto@keltia.freenix.fr |
| pb | Peter Blake ppb@baloo.tcp.co.uk |
| peter* | Peter Wemm peter@FreeBSD.org |
| phk* | Poul-Henning Kamp phk@FreeBSD.org |
| pst* | Paul Traina pst@FreeBSD.org |
| rb | Reinier Bezuidenhout rbezuide@oskar.nanoteq.co.za |
| rd | Rajiv Dighe rajivd@sprynet.com |
| rel | Roger Espel Llima espel@llaic.univ-bpclermont.fr |
| rjk | Richard J Kuhns rjk@grauel.com |
| rm | Robin Melville robmel@nadt.org.uk |
| rs | Robert Sexton robert@kudra.com |
| sc | Sergei Chechetkin csl@whale.sunbay.crimea.ua |
| tao | Brian Tao taob@risc.org |
| tdr | Thomas David Rivers ponds!rivers@dg-rtp.dg.com |
| witr | Robert Withrow witr@rwwa.com |
| xaa | Mark Huizer xaa@stack.nl |