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

For auditors, sync to latest roster and start using the fancier tables

Browse source 
generated by jmb's little TCL script.  Now you can just click on categories
or auditor/reviewers to email them.

Incorporate comments from Keith Bostic on security, point to AUSCERT's
Unix Security Checklist.
This commit is contained in:
Jordan K. Hubbard 1997-02-19 13:49:11 +00:00
parent dbb07c9784
commit 2d0b664dc7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=1188
4 changed files with 708 additions and 170 deletions
Download patch file Download diff file Expand all files Collapse all files

53
en/security.sgml
View file

@ -1,5 +1,5 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$Date: 1997-02-15 13:28:51 $">
<!ENTITY date "$Date: 1997-02-19 13:49:11 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
@ -14,7 +14,7 @@
<H1>FreeBSD Security Guide</H1>
<em>Last Updated: $Date: 1997-02-15 13:28:51 $ </em>
<em>Last Updated: $Date: 1997-02-19 13:49:11 $ </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
@ -24,16 +24,20 @@ 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.
<p>We welcome your comments on the contents and correctness of this page.
Please send email to <a href="mailto:security-officer@freebsd.org">the
FreeBSD Security Officers</a> if you have changes you'd like to see here.
<H2>How to secure a FreeBSD system:</H2>
<UL>
<LI>This section needs to be written.
<LI>XXX 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.
<LI>XXX This section also needs to be written.
</UL>
<H2>Security Do's and Don'ts for Programmers:</H2>
@ -50,8 +54,18 @@ to introduce security holes in the first place.
<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).
In fact, never use gets(3) or sprintf(3), period.
<P><LI><A NAME="#rule1_2"></A>Watch for strvis() and getenv() abuse.
<P><LI><A NAME="#rule1_2"></A>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!
<P><LI>Every time you see an open(2) or stat(2) call, ask yourself, "What
if it's a symbolic link?"
<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
@ -61,6 +75,9 @@ to introduce security holes in the first place.
<LI>Creating a directory. This will either succeed or fail.
<LI>Opening a file O_CREAT | O_EXCL
</UL>
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.
<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
@ -144,6 +161,32 @@ to introduce security holes in the first place.
<P><LI><A NAME="#rule6"></A>Pay special attention to realloc() usage - more
often than not, it's not done correctly.
<P><LI>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:
<LISTING>
char buf[1024];
struct foo { ... };
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
</LISTING>
<P><LI>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.
<P><LI>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.
<P>
</UL>
&footer;