diff --git a/data/security/Makefile b/data/security/Makefile
new file mode 100644
index 0000000000..947ceb0607
--- /dev/null
+++ b/data/security/Makefile
@@ -0,0 +1,12 @@
+# $Id: Makefile,v 1.1 1998-06-19 09:46:48 wosch Exp $
+
+.if exists(Makefile.conf)
+.include "Makefile.conf"
+.endif
+
+DOCS=
+DOCS+= programmers.sgml
+DOCS+= security.sgml
+DOCS+= secure.sgml
+
+.include "../web.mk"
diff --git a/data/security/programmers.html b/data/security/programmers.html
new file mode 100644
index 0000000000..ed31c0d3d8
--- /dev/null
+++ b/data/security/programmers.html
@@ -0,0 +1,205 @@
+
+
+
+Security Do's and Don'ts for Programmers
+
+
+Security Do's and Don'ts for Programmers
+
+
+
+
+
+
+- Never trust any source of input, i.e. command line
+ arguments, environment variables, configuration files, incoming UDP packets,
+ hostname lookups, function arguments, etc. If the length or contents of
+ the data received is at all subject to outside control then the program
+ or function should watch for this when copying it around. Specific
+ security issues to watch for in this area are:
+
+
+- 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).
+ In fact, never use gets(3) or sprintf(3), period.
+
+
+- strncpy() and strncat() calls. Be sure
+ you understand how these work\! strncpy() might not append a terminating
+ \\0 while strncat() always adds the \\0.
+
+
+- Watch for strvis(3) and getenv(3) abuse.
+ strvis() is easy to get the destination string wrong for, and getenv()
+ can return strings much longer than the user might expect - they are
+ one of the key ways an attack is often made on a program, causing it
+ to overwrite stack or variables by setting its environment variables
+ to unexpected values. If your program reads environment variables,
+ be paranoid!
+
+
+- Every time you see an open(2) or stat(2) call, ask yourself, "What
+ if it's a symbolic link?"
+
+
+- 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:
+
+- Creating a directory. This will either succeed or fail.
+
+- Opening a file O_CREAT | O_EXCL
+
+
+ mkstemp(3) properly handles this for you, so all temp files should
+ use mkstemp to guarantee there's no race and that the permissions
+ are right.
+
+
+- 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.
+
+
+- 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]
+
+
+- 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.
+
+
+- Look for holes or weaknesses in how data
+ is stored. All temp files should be 600 permission.
+
+
+- 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.
+
+
+- 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.
+
+
+
+
+- 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.
+
+
+- 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.
+
+
+- Tips for those reviewing existing code for security
+ problems:
+
+
+- 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. :)
+
+
+- Those without CVS commit privileges should make
+ sure that 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.
+
+
+- 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.
+
+
+- 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.
+
+
+- For committers: Be sure to retrofit -current
+ patches into the 2.2 and 2.1 branches as appropriate.
+
+
+- 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.
+
+
+
+
+- Look out for programs doing complex things in
+ signal handlers. Many routines in the various libraries are not
+ sufficiently reentrant to make this safe.
+
+
+- Pay special attention to realloc() usage - more
+ often than not, it's not done correctly.
+
+
+- When using fixed-size buffers, use sizeof() to prevent lossage when
+ a buffer size is changed but the code which uses it isn't. For example:
+ char buf[1024];
+ struct foo { ... };
+ ...
+BAD:
+ xxx(buf, 1024)
+ xxx(yyy, sizeof(struct foo))
+GOOD:
+ xxx(buf, sizeof(buf))
+ xxx(yyy, sizeof(yyy))
+
+Be careful though with sizeof of pointers when you really want the size
+of where it points to\!
+
+- Every time you see "char foo[###]", check every usage of foo to
+ make sure it can't be overflowed. If you can't avoid overflow
+ (and cases of this have been seen) then at least malloc the buffer
+ so you can't walk on the stack.
+
+
+- Always close file descriptors as soon as you can -- this makes it
+ more likely that the stdio buffer contents will be discarded. In
+ library routines, always set any file descriptors that you open to
+ close-on-exec.
+
+
+
+
+
+questions@FreeBSD.ORG
+ Copyright © 1995-1998 FreeBSD Inc.
+ All rights reserved.
$Date: 1998-06-19 09:46:50 $
+
diff --git a/data/security/secure.sgml b/data/security/secure.sgml
new file mode 100644
index 0000000000..58248fcafb
--- /dev/null
+++ b/data/security/secure.sgml
@@ -0,0 +1,60 @@
+
+
+
+ %includes;
+]>
+
+
+
+ &header;
+
+
+There are several steps involved in securing a FreeBSD system, or in
+fact any UNIX system:
+
+- disabling potentially dangerous software
+A lot of software has to be run as a special privileged user to make use
+of specific resources, bij making
+the executable set-uid. An example is UUCP software or PPP
+software that makes use of a serial port, or sendmail which has to write
+in the mail spool and bind to a network port. When you are not using
+UUCP, it is of little use to have the software on your system and it may
+be wise to disable it. Of course, this requires good knowlegde of what
+can be thrown away and what not, as well as a good indication whether or
+not you will want the functionality in the future.
+Also some utilities you may find not interesting enough to have them
+around and pose a possible security risk, like swapinfo. If you remove
+the set-uid bit for the executable (via chmod ug-s filename) you
+can always keep on using swapinfo when you're root. It is however
+not a good idea stripping so many sbits you have to be root all
+the time.
+Not only remove programs that you don't use, also remove services you
+don't want or need to provide. This can be done by editting the
+/etc/inetd.conf file and uncommenting out all services you
+don't use.
+ - fixing software with security bugs
+Subscribe yourself to mailinglist to get updates on security bugs in
+software and to get the fixes. Apply them immediately.
+ - checking your system on a regular basis
+With programs like COPS and SATAN you can find gaping holes and
+misconfigurations on your system. It is a good idea to run them
+occasionaly to see if you have made any mistakes.
+Also check the daily security reporting that FreeBSD send to root. Check
+the logfiles once in a while. Clean up unused accounts.
+ - being able to repair your system when security has been breached
+Always have backups and a clean version of the operating system (e.g. on
+CD-ROM).
+ - installing software that watches the system
+Programs like the tcp wrapper (a package with FreeBSD) and tripwire help you
+monitor activity on your system. This makes it easier to detect
+breakins.
+ - educating the people working on the system
+Users should know what they are doing, and e.g. use hard to guess
+password. Let them understand that the security of the system is partly
+in their hands.
+
+
+ &footer
+
+