os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

2.2 BETA -> 2.2 GAMMA (we really need a better way of keeping track of this

Browse source 
stuff; our pages age too quickly and people stop trusting them. :-( )

Very early draft of auditor/security page, just a place-holder for now.
This commit is contained in:
Jordan K. Hubbard 1997-02-15 06:45:28 +00:00
parent 9809a35308
commit 423b67a592
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=1159
8 changed files with 704 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
data/Makefile
View file

@ -1,13 +1,13 @@
# $Id: Makefile,v 1.10 1997-02-12 23:41:16 jfieber Exp $
# $Id: Makefile,v 1.11 1997-02-15 06:45:24 jkh Exp $
# These are turned into validated, normalized HTML files.
DOCS= about.sgml applications.sgml availability.sgml branch.sgml
DOCS= about.sgml applications.sgml auditors.sgml availability.sgml branch.sgml
DOCS+= cgallery.sgml commercial.sgml daemon.sgml docproj.sgml docs.sgml
DOCS+= features.sgml gallery.sgml includes.sgml index-site.sgml index.sgml
DOCS+= internet.sgml license.sgml mailto.sgml mirror.sgml newsflash.sgml
DOCS+= npgallery.sgml pgallery.sgml search.sgml searchhints.sgml send-pr.sgml
DOCS+= support.sgml welcome.sgml where.sgml resignation.sgml
DOCS+= security.sgml support.sgml welcome.sgml where.sgml resignation.sgml
# These will be directly installed.

196
data/auditors.sgml Normal file
View file

@ -0,0 +1,196 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-15 06:45:26 $">
<!ENTITY title "FreeBSD Auditing Project">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
<HTML>
<HEAD>
<TITLE>FreeBSD Source Auditing Project</TITLE>
<META NAME="Author" CONTENT="Jordan Hubbard">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#800080" ALINK="#FF
0000">
<H1>General Information</H1>
<em>Last Updated: $Date: 1997-02-15 06:45:26 $ </em>
<H2>Overview</H2>
<P>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.</P>
<P>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.</P>
<P>The core team's first step in becoming more serious about security
was to bring the project's security officer, <a href="mailto:guido@FreeBSD.org">
Guido van Rooij</a>, 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.</P>
<P>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.</P>
<P>Using the
<a href="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-CVS/CVSROOT/modules">
modules database</a> 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.</P>
<H2>Requirements:</H2>
<P>In order to be an auditor, you should either have commit privileges on
<em>freefall.freebsd.org</em> or an arrangement with another auditor/reviewer
who does. You should also be running or have immediate access to
<a href="handbook/current.html">FreeBSD-current</a> sources since all of our changes
will be made relative to that branch and then brought back (as necessary)
into the <strong>2.1</strong> and <strong>2.2</strong> branches.
<P>What to look for and what the general rules to follow are is sufficiently
complex that I have turned it into a <a href="security.html">FreeBSD
Security Guide</a>. Please read this now if you haven't already.
Another excellent document is the <a
href="ftp://ftp.auscert.org.au/pub/auscert/papers/secure_programming_checklist">
Secure Programming Checklist</a>, available from AUSCERT.
<H2>Sign-Up sheet:</H2>
<P>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.</P>
<P>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!</P>
<P>
<TABLE border=2 cellpadding=3>
<TR><TH>Module</TH> <TH>Auditor(s)</TH> <TH>Reviewer(s)</TH> <TH>Status</TH>
<TR><TD>lib</TD> <TD>pst</TD> <TD>jkh,dg,gvr,imp</TD> <TD></TD>
<TR><TD>libdisk</TD> <TD>open</TD> <TD>phk</TD> <TD>Open</TD>
<TR><TD>libexec</TD> <TD>imp</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>telnetd</TD> <TD>dn</TD> <TD>imp</TD> <TD>Open</TD>
<TR><TD>bin</TD> <TD>gvr</TD> <TD>imp</TD> <TD>Open</TD>
<TR><TD>sbin</TD> <TD>taob,imp</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>usr.sbin</TD> <TD>imp</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>usr.bin</TD> <TD>rb,rjk</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>eBones</TD> <TD>mrvm</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>secure</TD> <TD>mrvm</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>games</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>lkm</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>release</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>contrib</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
</TABLE>
<H2>Auditor/Reviewer keys</H2>
<P>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 <a
href="mailto:auditors@FreeBSD.org">auditors@FreeBSD.org</a> alias at
times when it is appropriate to do so.</P>
<TABLE cellpadding=2>
<TR><TH>Key</TH> <TH>Auditor/Reviewer Name and Email address</TH>
<TR><TD>ab</TD> <TD>Aaron Bornstein <a href="mailto:aaronb@j51.com">aaronb@j51.com</a></TD>
<TR><TD>ac</TD> <TD>Adrian Chadd <a href="mailto:adrian@wisdom.psinet.net.au">adrian@wisdom.psinet.net.au</a></TD>
<TR><TD>ak</TD> <TD>Adam Kubicki <a href="mailto:apk@itl.waw.pl">apk@itl.waw.pl</a></TD>
<TR><TD>am</TD> <TD>Albert Mietus <a href="mailto:albert@gamp.hacom.nl">albert@gamp.hacom.nl</a></TD>
<TR><TD>avk</TD> <TD>Alexander V. Kalganov <a href="mailto:top@sonic.cris.net">top@sonic.cris.net</a></TD>
<TR><TD>bb</TD> <TD>Bob Bishop <a href="mailto:rb@gid.co.uk">rb@gid.co.uk</a></TD>
<TR><TD>bob</TD> <TD>Bob Willcox <a href="mailto:bob@luke.pmr.com">bob@luke.pmr.com</a></TD>
<TR><TD>btm</TD> <TD>Brian T. Michely <a href="mailto:brianm@cmhcsys.com">brianm@cmhcsys.com</a></TD>
<TR><TD>cg</TD> <TD>Coranth Gryphon <a href="mailto:gryphon@healer.com">gryphon@healer.com</a></TD>
<TR><TD>cl</TD> <TD>Chris Lambertus <a href="mailto:cmlambertus@ucdavis.edu">cmlambertus@ucdavis.edu</a></TD>
<TR><TD>crh</TD> <TD>Charles Henrich <a href="mailto:henrich@crh.cl.msu.edu">henrich@crh.cl.msu.edu</a></TD>
<TR><TD>dc</TD> <TD>Dan Cross <a href="mailto:tenser@spitfire.ecsel.psu.edu">tenser@spitfire.ecsel.psu.edu</a></TD>
<TR><TD>dg*</TD> <TD>David Greenman <a href="mailto:davidg@FreeBSD.org">davidg@FreeBSD.org</a></TD>
<TR><TD>din</TD> <TD>Dinesh Nair <a href="mailto:dinesh@alphaque.com">dinesh@alphaque.com</a></TD>
<TR><TD>dn</TD> <TD>David Nugent <a href="mailto:davidn@labs.usn.blaze.net.au">davidn@labs.usn.blaze.net.au</a></TD>
<TR><TD>dz</TD> <TD>Danny J. Zerkel <a href="mailto:dzerkel@phofarm.com">dzerkel@phofarm.com</a></TD>
<TR><TD>eh</TD> <TD>Elijah Hempstone <a href="mailto:avatar@gandalf.bss.sol.net">avatar@gandalf.bss.sol.net</a></TD>
<TR><TD>eh</TD> <TD>Ernest Hua <a href="mailto:hua@chromatic.com">hua@chromatic.com</a></TD>
<TR><TD>ejc</TD> <TD>Eric J. Chet <a href="mailto:ejc@gargoyle.bazzle.com">ejc@gargoyle.bazzle.com</a></TD>
<TR><TD>gl</TD> <TD>Giles Lean <a href="mailto:giles@nemeton.com.au">giles@nemeton.com.au</a></TD>
<TR><TD>gvr*</TD> <TD>Guido van Rooij <a href="mailto:guido@FreeBSD.org">guido@FreeBSD.org</a></TD>
<TR><TD>gw</TD> <TD>Graham Wheeler <a href="mailto:gram@oms.co.za">gram@oms.co.za</a></TD>
<TR><TD>imp*</TD> <TD>Warner Losh <a href="mailto:imp@FreeBSD.org">imp@FreeBSD.org</a></TD>
<TR><TD>jb</TD> <TD>Jim Bresler <a href="mailto:jfb11@inlink.com">jfb11@inlink.com</a></TD>
<TR><TD>jha</TD> <TD>John H. Aughey <a href="mailto:jha@cs.purdue.edu">jha@cs.purdue.edu</a></TD>
<TR><TD>jk</TD> <TD>Jerry Kendall <a href="mailto:Jerry@kcis.com">Jerry@kcis.com</a></TD>
<TR><TD>jkh*</TD> <TD>Jordan K. Hubbard <a href="mailto:jkh@FreeBSD.org">jkh@FreeBSD.org</a></TD>
<TR><TD>jm</TD> <TD>Josef Moellers <a href="mailto:mollers.pad@sni.de">mollers.pad@sni.de</a></TD>
<TR><TD>jmb*</TD> <TD>Jonathan M. Bresler <a href="mailto:jmb@FreeBSD.org">jmb@FreeBSD.org</a></TD>
<TR><TD>joe*</TD> <TD>Joe Greco <a href="mailto:jgreco@solaria.sol.net">jgreco@solaria.sol.net</a></TD>
<TR><TD>ki</TD> <TD>Kenneth Ingham <a href="mailto:ingham@i-pi.com">ingham@i-pi.com</a></TD>
<TR><TD>ky*</TD> <TD>Kazutaka YOKOTA <a href="mailto:yokota@zodiac.mech.utsunomiya-u.ac.jp">yokota@zodiac.mech.utsunomiya-u.ac.jp</a></TD>
<TR><TD>marc</TD> <TD>Marc Slemko <a href="mailto:marcs@znep.com">marcs@znep.com</a></TD>
<TR><TD>md</TD> <TD>Matt Dillon <a href="mailto:dillon@best.net">dillon@best.net</a></TD>
<TR><TD>mr</TD> <TD>Mike Romaniw <a href="mailto:msr@cuc.com">msr@cuc.com</a></TD>
<TR><TD>mrvm*</TD> <TD>Mark Murray <a href="mailto:mark@grondar.za">mark@grondar.za</a></TD>
<TR><TD>or*</TD> <TD>Ollivier Robert <a href="mailto:roberto@keltia.freenix.fr">roberto@keltia.freenix.fr</a></TD>
<TR><TD>pb</TD> <TD>Peter Blake <a href="mailto:ppb@baloo.tcp.co.uk">ppb@baloo.tcp.co.uk</a></TD>
<TR><TD>peter*</TD> <TD>Peter Wemm <a href="mailto:peter@FreeBSD.org">peter@FreeBSD.org</a>
<TR><TD>phk*</TD> <TD>Poul-Henning Kamp <a href="mailto:phk@FreeBSD.org">phk@FreeBSD.org</a></TD>
<TR><TD>pst*</TD> <TD>Paul Traina <a href="mailto:pst@FreeBSD.org">pst@FreeBSD.org</a></TD>
<TR><TD>rb</TD> <TD>Reinier Bezuidenhout <a href="mailto:rbezuide@oskar.nanoteq.co.za">rbezuide@oskar.nanoteq.co.za</a></TD>
<TR><TD>rd</TD> <TD>Rajiv Dighe <a href="mailto:rajivd@sprynet.com">rajivd@sprynet.com</a></TD>
<TR><TD>rel</TD> <TD>Roger Espel Llima <a href="mailto:espel@llaic.univ-bpclermont.fr">espel@llaic.univ-bpclermont.fr</a></TD>
<TR><TD>rjk</TD> <TD>Richard J Kuhns <a href="mailto:rjk@grauel.com">rjk@grauel.com</a>
<TR><TD>rm</TD> <TD>Robin Melville <a href="mailto:robmel@nadt.org.uk">robmel@nadt.org.uk</a></TD>
<TR><TD>rs</TD> <TD>Robert Sexton <a href="mailto:robert@kudra.com">robert@kudra.com</a></TD>
<TR><TD>sc</TD> <TD>Sergei Chechetkin <a href="mailto:csl@whale.sunbay.crimea.ua">csl@whale.sunbay.crimea.ua</a></TD>
<TR><TD>tao</TD> <TD>Brian Tao <a href="mailto:taob@risc.org">taob@risc.org</a></TD>
<TR><TD>tdr</TD> <TD>Thomas David Rivers <a href="mailto:ponds!rivers@dg-rtp.dg.com">ponds!rivers@dg-rtp.dg.com</a></TD>
<TR><TD>witr</TD> <TD>Robert Withrow <a href="mailto:witr@rwwa.com">witr@rwwa.com</a></TD>
<TR><TD>xaa</TD> <TD>Mark Huizer <a href="mailto:xaa@stack.nl">xaa@stack.nl</a></TD>
</TABLE>
<h3>* = Has CVS commit privileges.</h3>
&footer;
</BODY>
</HTML>

151
data/security.sgml Normal file
View file

@ -0,0 +1,151 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-15 06:45:27 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
<HTML>
<HEAD>
<TITLE>FreeBSD Security Guide</TITLE>
<META NAME="Author" CONTENT="Jordan Hubbard">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#800080" ALINK="#FF
0000">
<H1>FreeBSD Security Guide</H1>
<em>Last Updated: $Date: 1997-02-15 06:45:27 $ </em>
<P>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.
<H2>How to secure a FreeBSD system:</H2>
<UL>
<LI>This section needs to be written.
</UL>
<H2>How to recover from a security compromise </H2>
<UL>
<LI>This section also needs to be written.
</UL>
<H2>Security Do's and Don'ts for Programmers:</H2>
<P><UL>
<LI><A NAME="#rule1"></A>Never trust any source of input, i.e. command line
arguments, environment variables, configuration files, incoming UDP packets,
hostname lookups, etc. If the length or contents of the data received
is at all subject to outside control then the program should watch
for this when copying it around. Specific security issues to watch for
in this area are:
<P><UL>
<LI><A NAME="#rule1_1"></A>strcpy() and sprintf() calls from
unbounded data. Use strncpy() and snprintf() when the length is known
(or implement some other form of bounds-checking when it's not).
<P><LI><A NAME="#rule1_2"></A>Watch for strvis() and getenv() abuse.
<P><LI><A NAME="#rule1_3"></A>All uses of mktemp(), tempnam(), mkstemp(),
etc.; make sure that they use mkstemp() instead. Also look for races in
/tmp in general, being aware that there are very few things can be atomic
in /tmp:
<UL>
<LI>Creating a directory. This will either succeed or fail.
<LI>Opening a file O_CREAT | O_EXCL
</UL>
<P><LI><A NAME="#rule1_4"></A>If an attacker can force packets to go/come
from another arbitrary system then that hacker has complete control
over the data that we get and *NONE* of it should be trusted.
<P><LI><A NAME="#rule1_5"></A>Understand the differences between uid,
euid and svuid in 2.1 and 2.2. We sure don't. [XXX but we should find out
and fill this in after talking to Bruce]
<P><LI><A NAME="#rule1_6"></A>Never trust that a config file is correctly
formatted or that it was generated by the appropriate utility. If there
is some chance for being sneaky, then some twisted cracker will try
to be sneaky: Don't trust user input like terminal names or language
strings to be free of '/' or ../../... embedded if there is any chance
that they can be used in a path name. Don't trust *ANY* paths supplied
by the user when you are running setuid root.
<P><LI><A NAME="#rule1_7"></A>Look for holes or weaknesses in how data
is stored. All temp files should be 600 permission.
<P><LI><A NAME="#rule1_8"></A>Don't just grep for the usual suspects
in programs which run at elevated privs. Look line by line for possible
overflows in these cases since there are a lot more ways than strcpy()
and friends to cause buffer overflows.
<P><LI><A NAME="#rule1_9"></A>Just because you drop privs somewhere doesn't
necessarily mean that no exploit is possible. The attacker may put the
necessary code on the stack to regain them before execing /bin/sh.
</UL>
<P><LI><A NAME="#rule2"></A>Do uid management. So drop privs as soon as possible,
and really drop them. Switching between euid and uid is not enough. Use
setuid() when you can.
<P><LI><A NAME="#rule3"></A>Never display configuration file contents on errors.
A line number and perhaps position count is enough. This is true for all
libs and for any SUID/SGID program.
<P><LI><A NAME="#rule4"></A>Tips for those reviewing existing code for security
problems:
<P><UL>
<LI><A NAME="#rule4_1"></A>If you're unsure of your security fixes, send them
to a reviewer with whom you've already made arrangements for a second glance
over. Don't commit code you're not sure of since breaking something in
the name of securing it is rather embarrassing. :)
<P><LI><A NAME="#rule4_2"></A>Those without CVS commit privileges should make
sure that at a reviewer with such privileges is among the last to review the
changes. That person will both review and incorporate the final version
you would like to have go into the tree.
<P><LI><A NAME="#rule4_3"></A>When sending changes around for review, always
use context or unidiff format diffs which may be easily fed to patch(1).
Do not simply send whole files! Diffs are much easier to read and apply to
local sources (especially those in which multiple, simultaneous changes
may be taking place). All changes should be relative to 3.0-current
just so we can all be working from a common base, unless there is strong
reason in a specific instance to do otherwise.
<P><LI><A NAME="#rule4_4"></A>Always directly test your changes (e.g. build and
run the affected module(s)) before sending them to a reviewer; no one likes
being sent obviously broken stuff for review, and it just makes it appear
as though the submitter didn't even really look at what he was
doing (which is hardly confidence-building). If you need accounts
on a 2.1, 2.2 or 3.0 machine in order to do proper testing, just
ask - the project has such resources available for just such
purposes.
<P><LI><A NAME="#rule4_5"></A>For committers: Be sure to retrofit -current
patches into the 2.2 and 2.1 branches as appropriate.
<P><LI><A NAME="#rule4_6"></A>Do not needlessly rewrite code to suit
your style/tastes - it only makes the reviewer's job needlessly more
difficult. Do so only if there are clear technical reasons for it.
</UL>
<P><LI><A NAME="#rule5"></A>Look out for programs doing complex things in
signal handlers. Many routines in the various libraries are not
sufficiently reentrant to make this safe.
<P><LI><A NAME="#rule6"></A>Pay special attention to realloc() usage - more
often than not, it's not done correctly.
</UL>
&footer;
</BODY>
</HTML>

4
data/where.sgml
View file

@ -1,5 +1,5 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-06 09:02:24 $">
<!ENTITY date "$Date: 1997-02-15 06:45:28 $">
<!ENTITY title "Getting FreeBSD">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
@ -38,7 +38,7 @@ href="ftp://ftp.freebsd.org/pub/FreeBSD">ftp://ftp.FreeBSD.org/pub/FreeBSD</a>:
<li><a href="&base/releases/2.1.6R/security.html">FreeBSD 2.1.6-RELEASE</a></li>
<li><a href="ftp://ftp.freebsd.org/pub/FreeBSD/2.2-BETA">FreeBSD 2.2-BETA</a></li>
<li><a href="ftp://ftp.freebsd.org/pub/FreeBSD/2.2-GAMMA">FreeBSD 2.2-GAMMA</a></li>
</ul>
</li>
<li>Anonymous ftp from one of the numerous <a

6
en/Makefile
View file

@ -1,13 +1,13 @@
# $Id: Makefile,v 1.10 1997-02-12 23:41:16 jfieber Exp $
# $Id: Makefile,v 1.11 1997-02-15 06:45:24 jkh Exp $
# These are turned into validated, normalized HTML files.
DOCS= about.sgml applications.sgml availability.sgml branch.sgml
DOCS= about.sgml applications.sgml auditors.sgml availability.sgml branch.sgml
DOCS+= cgallery.sgml commercial.sgml daemon.sgml docproj.sgml docs.sgml
DOCS+= features.sgml gallery.sgml includes.sgml index-site.sgml index.sgml
DOCS+= internet.sgml license.sgml mailto.sgml mirror.sgml newsflash.sgml
DOCS+= npgallery.sgml pgallery.sgml search.sgml searchhints.sgml send-pr.sgml
DOCS+= support.sgml welcome.sgml where.sgml resignation.sgml
DOCS+= security.sgml support.sgml welcome.sgml where.sgml resignation.sgml
# These will be directly installed.

196
en/auditors.sgml Normal file
View file

@ -0,0 +1,196 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-15 06:45:26 $">
<!ENTITY title "FreeBSD Auditing Project">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
<HTML>
<HEAD>
<TITLE>FreeBSD Source Auditing Project</TITLE>
<META NAME="Author" CONTENT="Jordan Hubbard">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#800080" ALINK="#FF
0000">
<H1>General Information</H1>
<em>Last Updated: $Date: 1997-02-15 06:45:26 $ </em>
<H2>Overview</H2>
<P>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.</P>
<P>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.</P>
<P>The core team's first step in becoming more serious about security
was to bring the project's security officer, <a href="mailto:guido@FreeBSD.org">
Guido van Rooij</a>, 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.</P>
<P>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.</P>
<P>Using the
<a href="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-CVS/CVSROOT/modules">
modules database</a> 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.</P>
<H2>Requirements:</H2>
<P>In order to be an auditor, you should either have commit privileges on
<em>freefall.freebsd.org</em> or an arrangement with another auditor/reviewer
who does. You should also be running or have immediate access to
<a href="handbook/current.html">FreeBSD-current</a> sources since all of our changes
will be made relative to that branch and then brought back (as necessary)
into the <strong>2.1</strong> and <strong>2.2</strong> branches.
<P>What to look for and what the general rules to follow are is sufficiently
complex that I have turned it into a <a href="security.html">FreeBSD
Security Guide</a>. Please read this now if you haven't already.
Another excellent document is the <a
href="ftp://ftp.auscert.org.au/pub/auscert/papers/secure_programming_checklist">
Secure Programming Checklist</a>, available from AUSCERT.
<H2>Sign-Up sheet:</H2>
<P>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.</P>
<P>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!</P>
<P>
<TABLE border=2 cellpadding=3>
<TR><TH>Module</TH> <TH>Auditor(s)</TH> <TH>Reviewer(s)</TH> <TH>Status</TH>
<TR><TD>lib</TD> <TD>pst</TD> <TD>jkh,dg,gvr,imp</TD> <TD></TD>
<TR><TD>libdisk</TD> <TD>open</TD> <TD>phk</TD> <TD>Open</TD>
<TR><TD>libexec</TD> <TD>imp</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>telnetd</TD> <TD>dn</TD> <TD>imp</TD> <TD>Open</TD>
<TR><TD>bin</TD> <TD>gvr</TD> <TD>imp</TD> <TD>Open</TD>
<TR><TD>sbin</TD> <TD>taob,imp</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>usr.sbin</TD> <TD>imp</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>usr.bin</TD> <TD>rb,rjk</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>eBones</TD> <TD>mrvm</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>secure</TD> <TD>mrvm</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>games</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>lkm</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>release</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
<TR><TD>contrib</TD> <TD>open</TD> <TD>open</TD> <TD>Open</TD>
</TABLE>
<H2>Auditor/Reviewer keys</H2>
<P>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 <a
href="mailto:auditors@FreeBSD.org">auditors@FreeBSD.org</a> alias at
times when it is appropriate to do so.</P>
<TABLE cellpadding=2>
<TR><TH>Key</TH> <TH>Auditor/Reviewer Name and Email address</TH>
<TR><TD>ab</TD> <TD>Aaron Bornstein <a href="mailto:aaronb@j51.com">aaronb@j51.com</a></TD>
<TR><TD>ac</TD> <TD>Adrian Chadd <a href="mailto:adrian@wisdom.psinet.net.au">adrian@wisdom.psinet.net.au</a></TD>
<TR><TD>ak</TD> <TD>Adam Kubicki <a href="mailto:apk@itl.waw.pl">apk@itl.waw.pl</a></TD>
<TR><TD>am</TD> <TD>Albert Mietus <a href="mailto:albert@gamp.hacom.nl">albert@gamp.hacom.nl</a></TD>
<TR><TD>avk</TD> <TD>Alexander V. Kalganov <a href="mailto:top@sonic.cris.net">top@sonic.cris.net</a></TD>
<TR><TD>bb</TD> <TD>Bob Bishop <a href="mailto:rb@gid.co.uk">rb@gid.co.uk</a></TD>
<TR><TD>bob</TD> <TD>Bob Willcox <a href="mailto:bob@luke.pmr.com">bob@luke.pmr.com</a></TD>
<TR><TD>btm</TD> <TD>Brian T. Michely <a href="mailto:brianm@cmhcsys.com">brianm@cmhcsys.com</a></TD>
<TR><TD>cg</TD> <TD>Coranth Gryphon <a href="mailto:gryphon@healer.com">gryphon@healer.com</a></TD>
<TR><TD>cl</TD> <TD>Chris Lambertus <a href="mailto:cmlambertus@ucdavis.edu">cmlambertus@ucdavis.edu</a></TD>
<TR><TD>crh</TD> <TD>Charles Henrich <a href="mailto:henrich@crh.cl.msu.edu">henrich@crh.cl.msu.edu</a></TD>
<TR><TD>dc</TD> <TD>Dan Cross <a href="mailto:tenser@spitfire.ecsel.psu.edu">tenser@spitfire.ecsel.psu.edu</a></TD>
<TR><TD>dg*</TD> <TD>David Greenman <a href="mailto:davidg@FreeBSD.org">davidg@FreeBSD.org</a></TD>
<TR><TD>din</TD> <TD>Dinesh Nair <a href="mailto:dinesh@alphaque.com">dinesh@alphaque.com</a></TD>
<TR><TD>dn</TD> <TD>David Nugent <a href="mailto:davidn@labs.usn.blaze.net.au">davidn@labs.usn.blaze.net.au</a></TD>
<TR><TD>dz</TD> <TD>Danny J. Zerkel <a href="mailto:dzerkel@phofarm.com">dzerkel@phofarm.com</a></TD>
<TR><TD>eh</TD> <TD>Elijah Hempstone <a href="mailto:avatar@gandalf.bss.sol.net">avatar@gandalf.bss.sol.net</a></TD>
<TR><TD>eh</TD> <TD>Ernest Hua <a href="mailto:hua@chromatic.com">hua@chromatic.com</a></TD>
<TR><TD>ejc</TD> <TD>Eric J. Chet <a href="mailto:ejc@gargoyle.bazzle.com">ejc@gargoyle.bazzle.com</a></TD>
<TR><TD>gl</TD> <TD>Giles Lean <a href="mailto:giles@nemeton.com.au">giles@nemeton.com.au</a></TD>
<TR><TD>gvr*</TD> <TD>Guido van Rooij <a href="mailto:guido@FreeBSD.org">guido@FreeBSD.org</a></TD>
<TR><TD>gw</TD> <TD>Graham Wheeler <a href="mailto:gram@oms.co.za">gram@oms.co.za</a></TD>
<TR><TD>imp*</TD> <TD>Warner Losh <a href="mailto:imp@FreeBSD.org">imp@FreeBSD.org</a></TD>
<TR><TD>jb</TD> <TD>Jim Bresler <a href="mailto:jfb11@inlink.com">jfb11@inlink.com</a></TD>
<TR><TD>jha</TD> <TD>John H. Aughey <a href="mailto:jha@cs.purdue.edu">jha@cs.purdue.edu</a></TD>
<TR><TD>jk</TD> <TD>Jerry Kendall <a href="mailto:Jerry@kcis.com">Jerry@kcis.com</a></TD>
<TR><TD>jkh*</TD> <TD>Jordan K. Hubbard <a href="mailto:jkh@FreeBSD.org">jkh@FreeBSD.org</a></TD>
<TR><TD>jm</TD> <TD>Josef Moellers <a href="mailto:mollers.pad@sni.de">mollers.pad@sni.de</a></TD>
<TR><TD>jmb*</TD> <TD>Jonathan M. Bresler <a href="mailto:jmb@FreeBSD.org">jmb@FreeBSD.org</a></TD>
<TR><TD>joe*</TD> <TD>Joe Greco <a href="mailto:jgreco@solaria.sol.net">jgreco@solaria.sol.net</a></TD>
<TR><TD>ki</TD> <TD>Kenneth Ingham <a href="mailto:ingham@i-pi.com">ingham@i-pi.com</a></TD>
<TR><TD>ky*</TD> <TD>Kazutaka YOKOTA <a href="mailto:yokota@zodiac.mech.utsunomiya-u.ac.jp">yokota@zodiac.mech.utsunomiya-u.ac.jp</a></TD>
<TR><TD>marc</TD> <TD>Marc Slemko <a href="mailto:marcs@znep.com">marcs@znep.com</a></TD>
<TR><TD>md</TD> <TD>Matt Dillon <a href="mailto:dillon@best.net">dillon@best.net</a></TD>
<TR><TD>mr</TD> <TD>Mike Romaniw <a href="mailto:msr@cuc.com">msr@cuc.com</a></TD>
<TR><TD>mrvm*</TD> <TD>Mark Murray <a href="mailto:mark@grondar.za">mark@grondar.za</a></TD>
<TR><TD>or*</TD> <TD>Ollivier Robert <a href="mailto:roberto@keltia.freenix.fr">roberto@keltia.freenix.fr</a></TD>
<TR><TD>pb</TD> <TD>Peter Blake <a href="mailto:ppb@baloo.tcp.co.uk">ppb@baloo.tcp.co.uk</a></TD>
<TR><TD>peter*</TD> <TD>Peter Wemm <a href="mailto:peter@FreeBSD.org">peter@FreeBSD.org</a>
<TR><TD>phk*</TD> <TD>Poul-Henning Kamp <a href="mailto:phk@FreeBSD.org">phk@FreeBSD.org</a></TD>
<TR><TD>pst*</TD> <TD>Paul Traina <a href="mailto:pst@FreeBSD.org">pst@FreeBSD.org</a></TD>
<TR><TD>rb</TD> <TD>Reinier Bezuidenhout <a href="mailto:rbezuide@oskar.nanoteq.co.za">rbezuide@oskar.nanoteq.co.za</a></TD>
<TR><TD>rd</TD> <TD>Rajiv Dighe <a href="mailto:rajivd@sprynet.com">rajivd@sprynet.com</a></TD>
<TR><TD>rel</TD> <TD>Roger Espel Llima <a href="mailto:espel@llaic.univ-bpclermont.fr">espel@llaic.univ-bpclermont.fr</a></TD>
<TR><TD>rjk</TD> <TD>Richard J Kuhns <a href="mailto:rjk@grauel.com">rjk@grauel.com</a>
<TR><TD>rm</TD> <TD>Robin Melville <a href="mailto:robmel@nadt.org.uk">robmel@nadt.org.uk</a></TD>
<TR><TD>rs</TD> <TD>Robert Sexton <a href="mailto:robert@kudra.com">robert@kudra.com</a></TD>
<TR><TD>sc</TD> <TD>Sergei Chechetkin <a href="mailto:csl@whale.sunbay.crimea.ua">csl@whale.sunbay.crimea.ua</a></TD>
<TR><TD>tao</TD> <TD>Brian Tao <a href="mailto:taob@risc.org">taob@risc.org</a></TD>
<TR><TD>tdr</TD> <TD>Thomas David Rivers <a href="mailto:ponds!rivers@dg-rtp.dg.com">ponds!rivers@dg-rtp.dg.com</a></TD>
<TR><TD>witr</TD> <TD>Robert Withrow <a href="mailto:witr@rwwa.com">witr@rwwa.com</a></TD>
<TR><TD>xaa</TD> <TD>Mark Huizer <a href="mailto:xaa@stack.nl">xaa@stack.nl</a></TD>
</TABLE>
<h3>* = Has CVS commit privileges.</h3>
&footer;
</BODY>
</HTML>

151
en/security.sgml Normal file
View file

@ -0,0 +1,151 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-15 06:45:27 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
<HTML>
<HEAD>
<TITLE>FreeBSD Security Guide</TITLE>
<META NAME="Author" CONTENT="Jordan Hubbard">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#800080" ALINK="#FF
0000">
<H1>FreeBSD Security Guide</H1>
<em>Last Updated: $Date: 1997-02-15 06:45:27 $ </em>
<P>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.
<H2>How to secure a FreeBSD system:</H2>
<UL>
<LI>This section needs to be written.
</UL>
<H2>How to recover from a security compromise </H2>
<UL>
<LI>This section also needs to be written.
</UL>
<H2>Security Do's and Don'ts for Programmers:</H2>
<P><UL>
<LI><A NAME="#rule1"></A>Never trust any source of input, i.e. command line
arguments, environment variables, configuration files, incoming UDP packets,
hostname lookups, etc. If the length or contents of the data received
is at all subject to outside control then the program should watch
for this when copying it around. Specific security issues to watch for
in this area are:
<P><UL>
<LI><A NAME="#rule1_1"></A>strcpy() and sprintf() calls from
unbounded data. Use strncpy() and snprintf() when the length is known
(or implement some other form of bounds-checking when it's not).
<P><LI><A NAME="#rule1_2"></A>Watch for strvis() and getenv() abuse.
<P><LI><A NAME="#rule1_3"></A>All uses of mktemp(), tempnam(), mkstemp(),
etc.; make sure that they use mkstemp() instead. Also look for races in
/tmp in general, being aware that there are very few things can be atomic
in /tmp:
<UL>
<LI>Creating a directory. This will either succeed or fail.
<LI>Opening a file O_CREAT | O_EXCL
</UL>
<P><LI><A NAME="#rule1_4"></A>If an attacker can force packets to go/come
from another arbitrary system then that hacker has complete control
over the data that we get and *NONE* of it should be trusted.
<P><LI><A NAME="#rule1_5"></A>Understand the differences between uid,
euid and svuid in 2.1 and 2.2. We sure don't. [XXX but we should find out
and fill this in after talking to Bruce]
<P><LI><A NAME="#rule1_6"></A>Never trust that a config file is correctly
formatted or that it was generated by the appropriate utility. If there
is some chance for being sneaky, then some twisted cracker will try
to be sneaky: Don't trust user input like terminal names or language
strings to be free of '/' or ../../... embedded if there is any chance
that they can be used in a path name. Don't trust *ANY* paths supplied
by the user when you are running setuid root.
<P><LI><A NAME="#rule1_7"></A>Look for holes or weaknesses in how data
is stored. All temp files should be 600 permission.
<P><LI><A NAME="#rule1_8"></A>Don't just grep for the usual suspects
in programs which run at elevated privs. Look line by line for possible
overflows in these cases since there are a lot more ways than strcpy()
and friends to cause buffer overflows.
<P><LI><A NAME="#rule1_9"></A>Just because you drop privs somewhere doesn't
necessarily mean that no exploit is possible. The attacker may put the
necessary code on the stack to regain them before execing /bin/sh.
</UL>
<P><LI><A NAME="#rule2"></A>Do uid management. So drop privs as soon as possible,
and really drop them. Switching between euid and uid is not enough. Use
setuid() when you can.
<P><LI><A NAME="#rule3"></A>Never display configuration file contents on errors.
A line number and perhaps position count is enough. This is true for all
libs and for any SUID/SGID program.
<P><LI><A NAME="#rule4"></A>Tips for those reviewing existing code for security
problems:
<P><UL>
<LI><A NAME="#rule4_1"></A>If you're unsure of your security fixes, send them
to a reviewer with whom you've already made arrangements for a second glance
over. Don't commit code you're not sure of since breaking something in
the name of securing it is rather embarrassing. :)
<P><LI><A NAME="#rule4_2"></A>Those without CVS commit privileges should make
sure that at a reviewer with such privileges is among the last to review the
changes. That person will both review and incorporate the final version
you would like to have go into the tree.
<P><LI><A NAME="#rule4_3"></A>When sending changes around for review, always
use context or unidiff format diffs which may be easily fed to patch(1).
Do not simply send whole files! Diffs are much easier to read and apply to
local sources (especially those in which multiple, simultaneous changes
may be taking place). All changes should be relative to 3.0-current
just so we can all be working from a common base, unless there is strong
reason in a specific instance to do otherwise.
<P><LI><A NAME="#rule4_4"></A>Always directly test your changes (e.g. build and
run the affected module(s)) before sending them to a reviewer; no one likes
being sent obviously broken stuff for review, and it just makes it appear
as though the submitter didn't even really look at what he was
doing (which is hardly confidence-building). If you need accounts
on a 2.1, 2.2 or 3.0 machine in order to do proper testing, just
ask - the project has such resources available for just such
purposes.
<P><LI><A NAME="#rule4_5"></A>For committers: Be sure to retrofit -current
patches into the 2.2 and 2.1 branches as appropriate.
<P><LI><A NAME="#rule4_6"></A>Do not needlessly rewrite code to suit
your style/tastes - it only makes the reviewer's job needlessly more
difficult. Do so only if there are clear technical reasons for it.
</UL>
<P><LI><A NAME="#rule5"></A>Look out for programs doing complex things in
signal handlers. Many routines in the various libraries are not
sufficiently reentrant to make this safe.
<P><LI><A NAME="#rule6"></A>Pay special attention to realloc() usage - more
often than not, it's not done correctly.
</UL>
&footer;
</BODY>
</HTML>

4
en/where.sgml
View file

@ -1,5 +1,5 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-06 09:02:24 $">
<!ENTITY date "$Date: 1997-02-15 06:45:28 $">
<!ENTITY title "Getting FreeBSD">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
@ -38,7 +38,7 @@ href="ftp://ftp.freebsd.org/pub/FreeBSD">ftp://ftp.FreeBSD.org/pub/FreeBSD</a>:
<li><a href="&base/releases/2.1.6R/security.html">FreeBSD 2.1.6-RELEASE</a></li>
<li><a href="ftp://ftp.freebsd.org/pub/FreeBSD/2.2-BETA">FreeBSD 2.2-BETA</a></li>
<li><a href="ftp://ftp.freebsd.org/pub/FreeBSD/2.2-GAMMA">FreeBSD 2.2-GAMMA</a></li>
</ul>
</li>
<li>Anonymous ftp from one of the numerous <a