Whitespace only commit.

Let Emacs rewrap the paragraphs after adding tags in the previous
commit.

Reviewed by:	chern
This commit is contained in:
Valentino Vaschetto 2001-09-12 21:51:14 +00:00
parent 07cfc90238
commit 84862aaf07
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=10670

View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.77 2001/09/08 00:29:27 logo Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.78 2001/09/12 21:44:24 logo Exp $
-->
<chapter id="security">
@ -378,28 +378,30 @@
<para>The prudent sysadmin 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
most bug-prone. For example, running an old version of
<application>imapd</application> or
<application>popper</application> 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 <application>ntalk</application>,
<application>popper</application> 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
<application>ntalk</application>,
<application>comsat</application>, and
<application>finger</application> daemons can be run in special
user <literal>sandboxes</literal>. A sandbox is not perfect, unless
you go through a large amount 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 <application>sshd</application> and never
login via <application>telnetd</application> or
user <literal>sandboxes</literal>. A sandbox is not perfect,
unless you go through a large amount 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
<application>sshd</application> and never login via
<application>telnetd</application> or
<application>rshd</application> or
<application>rlogind</application>, then turn off those
services!</para>
<para>FreeBSD now defaults to running
<application>ntalkd</application>,
<application>comsat</application>, and
@ -1472,12 +1474,14 @@ Edit O.K.
<sect2>
<title>Creating the Server File</title>
<para>We now have to extract all the instances which define the services
on each machine. For this we use the <command>ext_srvtab</command>
command. This will create a file which must be copied or moved
<emphasis>by secure means</emphasis> to each Kerberos client's
<filename>/etc/kerberosIV</filename> directory. This file must be present on each server
and client, and is crucial to the operation of Kerberos.</para>
<para>We now have to extract all the instances which define the
services on each machine. For this we use the
<command>ext_srvtab</command> command. This will create a file
which must be copied or moved <emphasis>by secure
means</emphasis> to each Kerberos client's
<filename>/etc/kerberosIV</filename> directory. This file must
be present on each server and client, and is crucial to the
operation of Kerberos.</para>
<screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
@ -1607,14 +1611,15 @@ Password changed.</screen>
<sect2>
<title>Adding <command>su</command> Privileges</title>
<para>Kerberos allows us to give <emphasis>each</emphasis> user who
needs root privileges their own <emphasis>separate</emphasis>
<command>su</command> password. We could now add an id which is
authorized to <command>su</command> to <username>root</username>.
This is controlled by having an instance of <username>root</username>
associated with a principal. Using <command>kdb_edit</command> we can
create the entry <literal>jane.root</literal> in the Kerberos
database:</para>
<para>Kerberos allows us to give <emphasis>each</emphasis> user
who needs root privileges their own
<emphasis>separate</emphasis> <command>su</command> password.
We could now add an id which is authorized to
<command>su</command> to <username>root</username>. This is
controlled by having an instance of <username>root</username>
associated with a principal. Using <command>kdb_edit</command>
we can create the entry <literal>jane.root</literal> in the
Kerberos database:</para>
<screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...