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

Whitespace only commit.

Browse source 
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
1 changed files with 36 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

63
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -1,7 +1,7 @@
<!-- <!--
The FreeBSD Documentation Project 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"> <chapter id="security">
@ -380,22 +380,24 @@
more, no less. Be aware that third party servers are often the 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>imapd</application> or
<application>popper</application> is like giving a universal root ticket out to the entire <application>popper</application> is like giving a universal
world. Never run a server that you have not checked out root ticket out to the entire world. Never run a server that
carefully. Many servers do not need to be run as root. For you have not checked out carefully. Many servers do not need to
example, the <application>ntalk</application>, be run as root. For example, the
<application>ntalk</application>,
<application>comsat</application>, and <application>comsat</application>, and
<application>finger</application> daemons can be run in special <application>finger</application> daemons can be run in special
user <literal>sandboxes</literal>. A sandbox is not perfect, unless user <literal>sandboxes</literal>. A sandbox is not perfect,
you go through a large amount of trouble, but the onion approach to unless you go through a large amount of trouble, but the onion
security still stands: If someone is able to break in through approach to security still stands: If someone is able to break
a server running in a sandbox, they still have to break out of the in through a server running in a sandbox, they still have to
sandbox. The more layers the attacker must break through, the break out of the sandbox. The more layers the attacker must
lower the likelihood of his success. Root holes have historically break through, the lower the likelihood of his success. Root
been found in virtually every server ever run as root, including holes have historically been found in virtually every server
basic system servers. If you are running a machine through which ever run as root, including basic system servers. If you are
people only login via <application>sshd</application> and never running a machine through which people only login via
login via <application>telnetd</application> or <application>sshd</application> and never login via
<application>telnetd</application> or
<application>rshd</application> or <application>rshd</application> or
<application>rlogind</application>, then turn off those <application>rlogind</application>, then turn off those
services!</para> services!</para>
@ -1472,12 +1474,14 @@ Edit O.K.
<sect2> <sect2>
<title>Creating the Server File</title> <title>Creating the Server File</title>
<para>We now have to extract all the instances which define the services <para>We now have to extract all the instances which define the
on each machine. For this we use the <command>ext_srvtab</command> services on each machine. For this we use the
command. This will create a file which must be copied or moved <command>ext_srvtab</command> command. This will create a file
<emphasis>by secure means</emphasis> to each Kerberos client's which must be copied or moved <emphasis>by secure
<filename>/etc/kerberosIV</filename> directory. This file must be present on each server means</emphasis> to each Kerberos client's
and client, and is crucial to the operation of Kerberos.</para> <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> <screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
@ -1607,14 +1611,15 @@ Password changed.</screen>
<sect2> <sect2>
<title>Adding <command>su</command> Privileges</title> <title>Adding <command>su</command> Privileges</title>
<para>Kerberos allows us to give <emphasis>each</emphasis> user who <para>Kerberos allows us to give <emphasis>each</emphasis> user
needs root privileges their own <emphasis>separate</emphasis> who needs root privileges their own
<command>su</command> password. We could now add an id which is <emphasis>separate</emphasis> <command>su</command> password.
authorized to <command>su</command> to <username>root</username>. We could now add an id which is authorized to
This is controlled by having an instance of <username>root</username> <command>su</command> to <username>root</username>. This is
associated with a principal. Using <command>kdb_edit</command> we can controlled by having an instance of <username>root</username>
create the entry <literal>jane.root</literal> in the Kerberos associated with a principal. Using <command>kdb_edit</command>
database:</para> we can create the entry <literal>jane.root</literal> in the
Kerberos database:</para>
<screen>&prompt.root; <userinput>kdb_edit</userinput> <screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database... Opening database...