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!
+ ++
| Module | Auditor(s) | Reviewer(s) | Status | +
|---|---|---|---|
| lib | pst | jkh,dg,gvr,imp | + |
| libdisk | open | phk | Open | +
| libexec | imp | open | Open | +
| telnetd | dn | imp | Open | +
| bin | gvr | imp | Open | +
| sbin | taob,imp | open | Open | +
| usr.sbin | imp | open | Open | +
| usr.bin | rb,rjk | open | Open | +
| eBones | mrvm | open | Open | +
| secure | mrvm | open | Open | +
| games | open | open | Open | +
| lkm | open | open | Open | +
| release | open | open | Open | +
| contrib | open | open | 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 do so.
+ +| Key | Auditor/Reviewer Name and Email address | +
|---|---|
| ab | Aaron Bornstein aaronb@j51.com | +
| ac | Adrian Chadd adrian@wisdom.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 | +
| dz | Danny J. Zerkel dzerkel@phofarm.com | +
| 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 | +
This guide attempts to document some of the tips and tricks used by +many FreeBSD security experts for securing systems and writing secure +code. It is designed to help you learn about the various ways of protecting +a FreeBSD system against outside attack and how to recover from such attacks +if and when they should happen. It also lists the various ways in which +the systems programmer can become more security conscious and less likely +to introduce security holes in the first place. + +
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!
+ ++
| Module | Auditor(s) | Reviewer(s) | Status | +
|---|---|---|---|
| lib | pst | jkh,dg,gvr,imp | + |
| libdisk | open | phk | Open | +
| libexec | imp | open | Open | +
| telnetd | dn | imp | Open | +
| bin | gvr | imp | Open | +
| sbin | taob,imp | open | Open | +
| usr.sbin | imp | open | Open | +
| usr.bin | rb,rjk | open | Open | +
| eBones | mrvm | open | Open | +
| secure | mrvm | open | Open | +
| games | open | open | Open | +
| lkm | open | open | Open | +
| release | open | open | Open | +
| contrib | open | open | 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 do so.
+ +| Key | Auditor/Reviewer Name and Email address | +
|---|---|
| ab | Aaron Bornstein aaronb@j51.com | +
| ac | Adrian Chadd adrian@wisdom.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 | +
| dz | Danny J. Zerkel dzerkel@phofarm.com | +
| 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 | +
This guide attempts to document some of the tips and tricks used by +many FreeBSD security experts for securing systems and writing secure +code. It is designed to help you learn about the various ways of protecting +a FreeBSD system against outside attack and how to recover from such attacks +if and when they should happen. It also lists the various ways in which +the systems programmer can become more security conscious and less likely +to introduce security holes in the first place. + +