Whitespace only commit.
Let Emacs rewrap the paragraphs after adding tags in the previous commit. Reviewed by: chern
This commit is contained in:
parent
07cfc90238
commit
84862aaf07
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=10670
1 changed files with 36 additions and 31 deletions
|
@ -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...
|
||||
|
|
Loading…
Reference in a new issue