Moving security page to section 7

2 files changed, 2 insertions, 476 deletions

diff --git a/share/man/man1/Makefile b/share/man/man1/Makefile
index e54e3a5..f1ed384 100644
--- a/share/man/man1/Makefile
+++ b/share/man/man1/Makefile
@@ -1,7 +1,7 @@
 #	@(#)Makefile	8.1 (Berkeley) 6/5/93
-#	$Id: Makefile,v 1.5 1998/12/19 09:33:03 dillon Exp $
+#	$Id: Makefile,v 1.6 1998/12/20 06:27:00 bde Exp $
 
-MAN1=	cd.1 intro.1 security.1 wait.1
+MAN1=	cd.1 intro.1 wait.1
 MLINKS=	intro.1 introduction.1
 
 .include <bsd.prog.mk>
diff --git a/share/man/man1/security.1 b/share/man/man1/security.1
deleted file mode 100644
index 9bca730..0000000
--- a/share/man/man1/security.1
+++ /dev/null
@@ -1,474 +0,0 @@
-.\" Copyright (c) 1991, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"     @(#)security.1	8.2 (Berkeley) 12/30/93
-.\"	$Id: security.1,v 1.2 1998/12/20 19:49:43 dillon Exp $
-.\"
-.Dd December 30, 1993
-.Dt SECURITY 1
-.Os
-.Sh NAME
-.Nm security
-.Nd introduction to security under FreeBSD
-.Sh DESCRIPTION
-.Pp
-Security is a function that begins and ends with the system administrator.
-While all
-.Bx
-systems are inherently multi-user capable, the job of building and
-maintaining security mechanisms to keep those users 'honest' is probably
-one of the single largest undertakings of the sysad.  Machines are
-only as secure as you make them, and security concerns are ever competing
-with the human necessity for convenience.   UNIX systems,
-in general, are capable of running a huge number of simultanious processes
-and many of these processes operate as servers - meaning that external entities
-can connect and talk to them.  As yesterday's mini-computers and mainframes 
-become today's desktops, and as computers become networked and internetworked,
-security becomes an ever bigger issue.
-.Pp
-Security concerns can be split up into several categories:
-.Bl -enum -offset indent
-.It
-Denial of service attacks
-.It
-User account compromises
-.It
-Root Hacks through accessible servers
-.It
-Root Hacks via user accounts
-.El
-.Pp
-A denial of service attack is an action that deprives the machine of needed
-resources.  Typically, D.O.S. attacks are brute-force mechanisms that attempt
-to crash or otherwise make a machine unusable by overwhelming its servers or
-network stack.  Some D.O.S. attacks try to take advantages of bugs in the
-networking stack to crash a machine with a single packet.  The latter can
-only be fixed by applying a bug fix to the kernel.  Attacks on servers can
-often be fixed by properly specifying options to servers to limit the load
-they incur on the system under adverse conditions.  Brute-force network 
-attacks are harder to deal with.  A spoofed-packet attack, for example, is 
-nearly impossible to stop short of cutting your system off from the internet.
-.Pp
-A user account compromise is even more common then a D.O.S. attack.  Many
-sysops still run standard telnetd, rlogind, rshd, and ftpd servers on their
-machines.  These servers, by default, do not operate over encrypted
-connections.  The result is that if you have any moderate-sized user base,
-one or more of your users logging into your system from a remote location
-(which is the most common and convenient way to login to a system) will
-have his or her password sniffed.  The attentive system admin will analyze
-his remote access logs occassionally looking for suspicious source addresses
-even for successful logins.
-.Pp
-One must always assume that once an attacker has access to a user account,
-the attacker can break root.  However, the reality is that in a well secured
-and maintained system, access to a user account does not necessarily give the
-attacker access to root.  The distinction is important because without access
-to root the attacker cannot generally hide his tracks and may, at best, be
-able to remove that user's files and crash the machine, but not touch anyone
-else's files.
-.Pp
-System administrators must keep in mind that there are several ways to break
-root on a machine.  The attacker may know the root password, the attacker
-may find a bug in a root-run server and be able to break root over a network
-connection to that server, or the attacker may know of a bug in an suid-root
-program that allows the attacker to break root once he has broken into a 
-user's account.
-.Pp
-Security remedies are always implemented in a multi-layered 'onion peel' 
-approach and can be categorized as follows:
-.Bl -enum -offset indent
-.It
-Securing root and staff accounts
-.It
-Securing root - root-run servers and suid/sgid binaries
-.It
-Securing user accounts
-.It
-Securing the password file 
-.It
-Securing the kernel core, raw devices, and filesystems
-.It
-Checking file integrity: binaries, config files, and so forth
-.It
-Paranoia
-.El
-.Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS
-.Pp
-Don't bother securing staff accounts if you haven't secured the root
-account.  Most systems have a password assigned to the root account.  The
-first thing you do is assume that the password is 'always' compromised.
-To secure the root account you make sure that it is not possible to login
-to the root account using the root password from a random user account or 
-over the network.  If you haven't already, configure telnetd, rlogind, and
-all other servers that handle login operations to refuse root logins, period,
-whether the right password is given or not.  Allow direct root logins only
-via the system console.  The '/etc/ttys' file comes in handy here and is
-secure by default on most systems, but a good sysad always checks to make sure.
-.Pp
-Of course, as a sysad you have to be able to get to root, so we open up
-a few holes.  But we make sure these holes require additional password
-verification to operate.  One way to make root accessible is to add appropriate
-staff accounts to the wheel group (in /etc/group).  The staff members placed
-in the wheel group are allowed to 'su' to root.  You should never give staff
-members native wheel access via their entry in the password file... put staff
-in a 'staff' group or something and only add those that really need root to
-the wheel group.  Unfortunately the wheel mechanism still allows a hacker to
-break root if the hacker has gotten hold of your password file - he need only
-break the root password and the password of one of the staff accounts that
-happens to be in the wheel group.  So while the wheel mechanism is useable,
-it isn't much safer then not having a wheel group at all.
-.Pp
-An indirect way to secure the root account is to secure your staff accounts
-by using an alternative login access method and *'ing out the crypted password
-for the staff accounts.  This way a hacker may be able to steal the password
-file but will not be able to break into any staff accounts (or, indirectly,
-root, even if root has a crypted password associated with it).  Staff members
-get into their staff accounts through a secure login mechanism such as 
-kerberos(1) or ssh(1) (see /usr/ports/security/ssh) using a private/public
-keypair.  When you use something like kerberos you generally must secure
-the machines which run the kerberos servers and your desktop workstation.
-When you use a public/private keypair with ssh, you must generally secure
-the machine you are logging in FROM (typically your workstation), but you can
-also add an additional layer of protection to the keypair by password 
-protecting the keypair when you create it with ssh-keygen(1).  Being able
-to *-out the passwords for staff accounts also guarentees that staff members
-can only login through secure access methods that you have setup.  You can
-thus force all staff members to use secure, encrypted connections for
-all their sessions which closes an important hole used by many hackers:  That
-of sniffing the network from an unrelated, less secure machine.
-.Pp
-The more indirect security mechanisms also assume that you are logging in
-from a more restrictive server to a less restrictive server.  For example, 
-if your main box is running all sorts of servers, your workstation shouldn't
- be running any.  In order for your workstation to be reasonably secure 
-you should run as few servers as possible, up to and including no servers 
-at all, and you should run a password-protected screen blanker. 
- Of course, given physical access to
-a workstation an attacker can break any sort of security you put on it.
-This is definitely a problem that you should consider but you should also
-consider the fact that the vast majority of breakins occur remotely, over
-a network, from peopl who do not have physical access to your workstation or
-servers.
-.Pp
-Using something like kerberos also gives you the ability to disable or
-change the password for a staff account in one place and have it immediately
-effect all the machine the staff member may have an account on.  If a staff
-member's account gets compromised, the ability to instantly change his 
-password on all machines should not be underrated.  With discrete passwords,
-changing a password on N machines can be a mess.  You can also impose 
-re-passwording restrictions with kerberos:  not only can a kerberos ticket
-be made to timeout after a while, but the kerberos system can require that
-the user choose a new password after a certain period of time (say, once a 
-month). 
-.Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES
-.Pp
-The prudent sysop only runs the servers he needs to, no more, no less.  Be
-aware that third party servers are often the most bug-prone.  For example,
-running an old version of imapd or popper is like giving a universal root
-ticket out to the entire world.  Never run a server that you have not checked
-out carefully.  Many servers do not need to be run as root.  For example,
-the ntalk, comsat, and finger daemons can be run in special user 'sandboxes'.
-A sandbox isn't perfect unless you go to a hellofalot of trouble, but the
-onion approach to security still stands:  If someone is able to break in
-through a server running in a sandbox, they still have to break out of the
-sandbox.  The more layers the attacker must break through, the lower the
-likelihood of his success.  Root holes have historically been found in
-virtually every server ever run as root, including basic system servers.
-If you are running a machine through which people only login via sshd and
-never login via telnetd or rshd or rlogind, then turn off those services!
-.Pp
-FreeBSD now defaults to running ntalkd, comsat, and finger in a sandbox.
-Another program which may be a candidate for running in a sandbox is
-named(8).  The default rc.conf includes the arguments necessary to run
-named in a sandbox in a commented-out form.  Depending on whether you
-are installing a new system or upgrading an existing system, the special
-user accounts used by these sandboxes may not be installed.  The prudent
-sysop would research and implement sandboxes for servers whenever possible.
-.Pp
-There are a number of other servers that typically do not run in sandboxes:
-sendmail, popper, imapd, ftpd, and others.  There are alternatives to
-some of these, but installing them may require more work then you are willing
-to put (the convenience factor strikes again).  You may have to run these
-servers as root and rely on other mechanisms to detect breakins that might
-occur through them.
-.Pp
-The other big potential root hole in a system are the suid-root and sgid
-binaries installed on the system.  Most of these binaries, such as rlogin,
-reside in /bin, /sbin, /usr/bin, or /usr/sbin.  While nothing is 100% safe,
-the system-default suid and sgid binaries can be considered reasonably safe.
-Still, root holes are occassionaly found in these binaries.  A root hole
-was found in Xlib in 1998 that made xterm (which is typically suid) vulnerable.
-It is better to be safe then sorry and the prudent sysad will restrict suid
-binaries that only staff should run to a special group that only staff can
-access, and get rid of (chmod 000) any suid binaries that nobody uses.  A 
-server with no display generally does not need an xterm binary.  Sgid binaries
-can be almost as dangerous.  If a hacker can break an sgid-kmem binary the
-hacker might be able to read /dev/kmem and thus read the crypted password
-file, potentially compromising any passworded account.  A hacker that breaks
-the tty group can write to almost user's tty.  If a user is running a terminal
-program or emulator with a talk-back feature, the hacker can potentially 
-generate a data stream that causes the user's terminal to echo a command, which
-is then run as that user.
-.Sh SECURING USER ACCOUNTS
-.Pp
-User accounts are usually the most difficult to secure.  While you can impose
-draconian access restrictions on your staff and *-out their passwords, you
-may not be able to do so with any general user accounts you might have.  If
-you do have sufficient control then you may win out and be able to secure the
-user accounts properly.  If not, you simply have to be more vigilant in your
-monitoring of those accounts.  Use of ssh and kerberos for user accounts is
-more problematic, but still a very good solution compared to a crypted
-password. 
-.Sh SECURING THE PASSWORD FILE
-.Pp
-The only sure fire way is to *-out as many passwords as you can and 
-use ssh or kerberos for access to those accounts.  Even though the 
-crypted password file (/etc/spwd.db) can only be read by root, it may
-be possible for a hacker to obtain read access to that file even if the 
-attacker cannot obtain root-write access.
-.Pp
-Your security scripts should always check for and report changes to 
-the password file (see 'Checking file integrity' below).
-.Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS
-.Pp
-If an attacker breaks root he can do just about anything, but there
-are certain conveniences.  For example, most modern kernels have a
-packet sniffing device driver built in.  Under FreeBSD it is called
-the 'bpf' device.  A hacker will commonly attempt to run a packet sniffer
-on a compromised machine.  You do not need to give the hacker the 
-capability and most systems should not have the bpf device compiled in.
-Unfortunately, there is another kernel feature called the Loadable Kernel
-Module interface.  An enterprising hacker can use an LKM to install 
-his own bpf device or other sniffing device on a running kernel.  If you
-do not need to use the module loader, turn it off in the kernel config
-with the NO_LKM option.
-.Pp
-But even if you turn off the bpf device, and turn off the module loader,
-you still have /dev/mem and /dev/kmem to worry about.  For that matter,
-the hacker can still write raw devices.  To avoid this you have to run
-the kernel at a higher secure level... at least securelevel 1.  The securelevel
-can be set with a sysctl on the kern.securelevel variable.  Once you have
-set the securelevel to 1, write access to raw devices will be denied and
-special chflags flags, such as 'schg', will be enforced.  You must also ensure
-that the 'schg' flag is set on critical startup binaries, directories, and
-script files - everything that gets run up to the point where the securelevel
-is set.  This might be overdoing it, and upgrading the system is much more
-difficult when you operate at a higher secure level.  You may compromise and
-run the system at a higher secure level but not set the schg flag for every
-system file and directory under the sun.
-.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
-.Pp
-When it comes right down to it, you can only protect your core system
-configuration and control files so much before the convenience factor
-rears its ugly head.  The last layer of your security onion is perhaps
-the most important - detection.
-.Pp
-The only correct way to check a system's file integrity is via another,
-more secure system.  It is fairly easy to setup a 'secure' system: you
-simply do not run any services on it.  With a secure system in place you
-can then give it access to other system's root spaces via ssh.  This may
-seem like a security breech, but you have to put your trust somewhere and
-as long as you don't do something stupid like run random servers it really
-is possible to build a secure machine.  When I say 'secure' here, I assuming
-physical access security as well, of course.  Given a secure machine with
-root access on all your other machines, you can then write security scripts
-ON the secure machine to check the other machines on the system.  The most
-common way of checking is to have the security script scp(1) over a find
-and md5 binary and then ssh a shell command to the remote machine to md5
-all the files in the system (or, at least, the /, /var, and /usr partitions!).
-The security machine copies the results to a file and diff's them against
-results from a previous run (or compares the results against its own 
-binaries), then emails each staff member a daily report of differences.
-.Pp
-Another way to do this sort of check is to NFS export the major filesystems
-from every other machine to the security machine.  This is somewhat more
-network intensive but also virtually impossible for a hacker to detect
-or spoof.
-.Pp
-A good security script will also check for changes to user and staff members
-access configuration files:  .rhosts, .shosts, .ssh/authorized_keys, and
-so forth... files that might fall outside the pervue of the MD5 check.
-.Pp
-A good security script will check for suid and sgid binaries on all 
-filesystems and report their absolute existance as well as a diff against
-the previous report or some baseline (say, make a baseline once a week).
-While you can turn off the ability to run suid and sgid binaries on certain
-filesystems through the 'nosuid' option in fstab/mount, you cannot turn this
-off on root and anyone who breaks root can just install their binary their.
-If you have a huge amount of user disk space, though, it may be useful to
-disallow suid binaries and devices ('nodev' option) on the user partitions
-so you do not have to scan them for such.  I would scan them anyway, though,
-at least once a week, since the object of this onion layer is detection of
-a breakin.
-.Pp
-Process accounting (see accton(1)) is a relatively low-overhead feature of
-the operating system which I recommend using as a post-breakin evaluation
-mechanism.  It is especially useful in tracking down how a hacker has 
-actually broken root on a system, assuming the file is still intact after
-the breakin occurs.
-.Pp
-Finally, security scripts should process the log files and the logs themselves
-should be generated in as secured a manner as possible - remote syslog can be
-very useful.  A hacker tries to cover his tracks, and log files are critical
-to the sysop trying to track down the time and method of the initial breakin.
-.Sh PARANOIA
-.Pp
-A little paranoia never hurts.  As a rule, a sysop can add any number
-of security features as long as they do not effect convenience, and 
-can add security features that do effect convenience with some added
-thought.
-.Sh SPECIAL SECTION ON D.O.S. ATTACKS
-.Pp
-This section covers Dential of Service attacks.  A DOS attack is typically
-a packet attack.  While there isn't much you can do about modern spoofed
-packet attacks that saturate your network, you can generally limit the damage
-by ensuring that the attacks cannot take down your servers.  
-.Bl -enum -offset indent
-.It
-Limiting server forks
-.It
-Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...)
-.It
-Kernel Route Cache
-.El
-.Pp
-A common DOS attack is against a forking server that attempts to cause the
-server to eat processes, file descirptors, and memory until the machine
-dies.  Inetd (see inetd(8)) has several options to limit this sort of attack.
-It should be noted that while it is possible to prevent a machine from going
-down it is not generally possible to prevent a service from being disrupted 
-by the attack.  Read the inetd manual page carefully and pay specific attention
-to the -c, -C, and -R options.  Note that spoofed-IP attacks will circumvent
-the -C option to inetd, so typically a combination of options must be used.
-Some standalone servers have self-fork-limitation parameters.  
-.Pp
-Sendmail has its -OMaxDaemonChildren option which tends to work much
-better then trying to use sendmail's load limiting options due to the
-load lag.  You should specify a MaxDaemonChildren parameter when you start
-sendmail high enough to handle your expected load but no so high that the
-computer cannot handle that number of sendmails without falling on its face. 
-It is also prudent to run sendmail in queued mode (-ODeliveryMode=queued)
-and to run the daemon (sendmail -bd) separate from the queue-runs
-(sendmail -q15m).   If you still want realtime delivery you can run the queue
-at a much lower interval, such as -q1m, but be sure to specify a reasonable
-MaxDaemonChildren option for that sendmail to prevent cascade failures.
-.Pp
-Syslogd can be attacked directly and it is strongly recommended that you use
-the -s option whenever possible, and the -a option otherwise.
-.Pp
-You should also be fairly careful
-with connect-back services such as tcpwrapper's reverse-identd, which can 
-be attacked directly.  You generally do not want to use the reverse-ident
-feature of tcpwrappers for this reason.
-.Pp
-It is a very good idea to protect internal services from external access
-by firewalling them off at your border routers.  The idea here is to prevent
-saturation attacks from outside your LAN, not so much to protect internal 
-services from root network-based root hacks.  Always configure an exclusive
-firewall, i.e. 'firewall everything *except* ports A, B, C, D, and M-Z'.   This
-way you can firewall off all of your low ports except for certain specific
-services such as named (if you are primary for a zone), ntalkd, sendmail,
-and other internet-accessible services.
-If you try to configure the firewall the other
-way - as an inclusive or permissive firewall, there is a good chance that you
-will forget to 'close' a couple of services or that you will add a new internal
-service and forget to update the firewall.  You can still open up the 
-high-numbered port range on the firewall to allow permissive-like operation
-without compromising your low ports.  Also take note that FreeBSD allows you to
-control the range of port numbers used for dynamic binding via the various
-net.inet.ip.portrange sysctl's (sysctl -a | fgrep portrange), which can also
-ease the complexity of your firewall's configuration.  I usually use a normal
-first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then
-block everything under 4000 off in my firewall ( except for certain specific
-internet-accessible ports, of course ).
-.Pp
-Another common DOS attack is called a springboard attack - to attack a server
-in a manner that causes the server to generate responses which then overload
-the server, the local network, or some other machine.  The most common attack
-of this nature is the ICMP PING BROADCAST attack.  The attacker spoofed ping
-packets sent to your LAN's broadcast address with the source IP address set
-to the actual machine they wish to attack.  If your border routers are not
-configured to stomp on ping's to broadcast addresses, your LAN winds up
-generating sufficient responses to the spoofed source address to saturate the
-victim, especially when the attacker uses the same trick on several dozen
-broadcast addresses over several dozen different networks at once.  Broadcast
-attacks of over a hundred and twenty megabits have been measured.  A second
-common springboard attack is against the ICMP error reporting system.  By
-constructing packets that generate ICMP error responses, an attacker can 
-saturate a server's incoming network and cause the server to saturate its 
-outgoing network with ICMP responses.  This type of attack can also crash the
-server by running it out of mbuf's, especially if the server cannot drain the
-ICMP responses it generates fast enough.  The FreeBSD kernel has a new kernel
-compile option called ICMP_BANDLIM which limits the effectiveness of these 
-sorts of attacks.  The last major class of springboard attacks is related to
-certain internal inetd services such as the udp echo service.  An attacker 
-simply spoofs a UDP packet with the source address being server A's echo port,
-and the destination address being server B's echo port, where server A and B
-are both on your LAN.  The two servers then bounce this one packet back and
-forth between each other.  The attacker can overload both servers and their
-LANs simply by injecting a few packets in this manner.  Similar problems
-exist with the internal chargen port.  A competent sysad will turn off all
-of these inetd-internal test services.
-.Pp
-Spoofed packet attacks may also be used to overload the kernel route cache.
-Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl 
-parameters.  A spoofed packet attack that uses a random source IP will cause
-the kernel to generate a temporary cached route in the route table, viewable
-with 'netstat -rna | fgrep W3'.  These routes typically timeout in 1600
-seconds or so.  If the kernel detects that the cached route table has gotten
-too big it will dynamically reduce the rtexpire but will never decrease it to
-less then rtminexpire.  There are two problems:  (1) The kernel does not react
-quickly enough when a lightly loaded server is suddenly attacked, and (2) The
-rtminexpire is not low enough for the kernel to survive a sustained attack.
-If your servers are connected to the internet via a T3 or better it may be 
-prudent to manually override both rtexpire and rtminexpire via sysctl(8).
-Never set either parameter to zero (unless you want to crash the machine :-)).
-Setting both parameters to 2 seconds should be sufficient to protect the route
-table from attack.
-
-.Sh SEE ALSO
-.Pp
-.Xr ssh 1 ,
-.Xr sshd 1 ,
-.Xr kerberos 1 ,
-.Xr accton 1 ,
-.Xr xdm 1 ,
-.Xr syslogd 1 ,
-.Xr chflags 1 ,
-.Xr find 1 ,
-.Xr md5 1 ,
-.Xr sysctl 8
-.Sh HISTORY
-The
-.Nm
-manual page was originally written by Matthew Dillon and first appeared 
-in FreeBSD-3.0.1, December 1998.
-