svn commit: r44726 - head/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Wed Apr 30 21:29:04 UTC 2014
Author: dru
Date: Wed Apr 30 21:29:03 2014
New Revision: 44726
URL: http://svnweb.freebsd.org/changeset/doc/44726
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 20:50:57 2014 (r44725)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 21:29:03 2014 (r44726)
@@ -116,61 +116,61 @@
in any system could allow intruders to gain access to critical
information and cause havoc on an entire network. One of the
core principles of information security is the
- <acronym>CIA</acronym> triad, which stands for the Confidentiality,
- Integrity, and Availability of information systems.</para>
+ <acronym>CIA</acronym> triad, which stands for the
+ Confidentiality, Integrity, and Availability of information
+ systems.</para>
<para>The <acronym>CIA</acronym> triad is a bedrock concept of
computer security as customers and users expect their data to be
- protected. For example, a customer expects that their credit card
- information is securely stored (confidentiality), that their
- orders are not changed behind the scenes (integrity), and that they have
- access to their order information at all times (availablility).</para>
+ protected. For example, a customer expects that their credit
+ card information is securely stored (confidentiality), that
+ their orders are not changed behind the scenes (integrity), and
+ that they have access to their order information at all times
+ (availablility).</para>
<para>To provide <acronym>CIA</acronym>, security professionals
- apply a defense in depth strategy. The idea of defense in
- depth is to add several layers of security to prevent one single
- layer failing and the entire security system collapsing. For example, a
- system administrator cannot simply turn on a firewall and
- consider the network or system secure. One must also audit accounts,
- check the integrity of binaries, and ensure malicious tools are
- not installed. To implement an effective security strategy, one must understand
- threats and how to defend against them.</para>
-
- <para>What is a threat as it pertains to computer security? Threats
- are not limited to remote attackers who
- attempt to access a system without permission
- from a remote location. Threats also include
- employees, malicious software, unauthorized
- network devices, natural disasters, security vulnerabilities,
- and even competing corporations.</para>
-
- <para>Systems and networks can be
- accessed without permission,
- sometimes by accident, or by remote attackers, and
- in some cases, via corporate espionage or former employees. As a
- user, it is important to prepare for and admit when a
- mistake has lead to a security breach and report possible
- issues to the security team. As an administrator, it is
- important to know of the threats and be prepared to mitigate
- them.</para>
-
- <para>When applying security to systems, it is recommended to
- start by securing the basic
- accounts and system configuration, and then to secure
- the network layer so that it adheres to the system policy
- and the organization's security procedures. Many organizations already have a security policy
- that covers the configuration of technology devices. The policy
- should include the security configuration of
- workstations, desktops, mobile devices, phones,
- production servers, and development servers. In
- many cases, standard
- operating procedures (<acronym>SOP</acronym>s) already exist.
- When in doubt, ask the security team.</para>
+ apply a defense in depth strategy. The idea of defense in depth
+ is to add several layers of security to prevent one single layer
+ failing and the entire security system collapsing. For example,
+ a system administrator cannot simply turn on a firewall and
+ consider the network or system secure. One must also audit
+ accounts, check the integrity of binaries, and ensure malicious
+ tools are not installed. To implement an effective security
+ strategy, one must understand threats and how to defend against
+ them.</para>
+
+ <para>What is a threat as it pertains to computer security?
+ Threats are not limited to remote attackers who attempt to
+ access a system without permission from a remote location.
+ Threats also include employees, malicious software, unauthorized
+ network devices, natural disasters, security vulnerabilities,
+ and even competing corporations.</para>
+
+ <para>Systems and networks can be accessed without permission,
+ sometimes by accident, or by remote attackers, and in some
+ cases, via corporate espionage or former employees. As a user,
+ it is important to prepare for and admit when a mistake has lead
+ to a security breach and report possible issues to the security
+ team. As an administrator, it is important to know of the
+ threats and be prepared to mitigate them.</para>
+
+ <para>When applying security to systems, it is recommended to
+ start by securing the basic accounts and system configuration,
+ and then to secure the network layer so that it adheres to the
+ system policy and the organization's security procedures. Many
+ organizations already have a security policy that covers the
+ configuration of technology devices. The policy should include
+ the security configuration of workstations, desktops, mobile
+ devices, phones, production servers, and development servers.
+ In many cases, standard operating procedures
+ (<acronym>SOP</acronym>s) already exist. When in doubt, ask the
+ security team.</para>
<para>The rest of this introduction describes how some of these
basic security configurations are performed on a &os; system.
The rest of this chapter describes some specific tools which can
- be used when implementing a security policy on a &os; system.</para>
+ be used when implementing a security policy on a &os;
+ system.</para>
<sect2 xml:id="security-accounts">
<title>Preventing Logins</title>
@@ -178,55 +178,57 @@
<para>In securing a system, a good starting point is an audit of
accounts. Ensure that <systemitem
class="username">root</systemitem> has a strong password and
- that this password is not shared.
- Disable any accounts that do not need login access.</para>
+ that this password is not shared. Disable any accounts that
+ do not need login access.</para>
- <para>To deny login access to accounts, two methods exist. The first
- is to lock the account. This example locks the <systemitem
- class="username">toor</systemitem> account:</para>
+ <para>To deny login access to accounts, two methods exist. The
+ first is to lock the account. This example locks the
+ <systemitem class="username">toor</systemitem> account:</para>
<screen>&prompt.root; <userinput>pw lock <replaceable>toor</replaceable></userinput></screen>
- <para>The second method is to prevent login access
- by changing the shell to <filename>/sbin/nologin</filename>.
- Only the superuser can change the shell for other users:</para>
+ <para>The second method is to prevent login access by changing
+ the shell to <filename>/sbin/nologin</filename>. Only the
+ superuser can change the shell for other users:</para>
<screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin <replaceable>toor</replaceable></userinput></screen>
<para>The <filename>/usr/sbin/nologin</filename> shell prevents
- the system from assigning a shell to the
- user when they attempt to login.</para>
+ the system from assigning a shell to the user when they
+ attempt to login.</para>
</sect2>
<sect2 xml:id="security-sudo">
<title>Permitted Account Escalation</title>
- <para>In some cases, system administration needs to be
- shared with other users. &os; has two methods to handle this.
- The first one, which is not recommended, is a shared root
- password used by members of the <systemitem
- class="groupname">wheel</systemitem> group. With this method,
- a user types <command>su</command> and enters the password for
- <systemitem class="groupname">wheel</systemitem> whenever
- superuser access is needed. The user should then type
- <command>exit</command> to leave privileged access after
- finishing the commands that required administrative access. To add a user
- to this group, edit <filename>/etc/group</filename> and add the
- user to the end of the <literal>wheel</literal> entry. The user must be
+ <para>In some cases, system administration needs to be shared
+ with other users. &os; has two methods to handle this. The
+ first one, which is not recommended, is a shared root password
+ used by members of the <systemitem
+ class="groupname">wheel</systemitem> group. With this
+ method, a user types <command>su</command> and enters the
+ password for <systemitem class="groupname">wheel</systemitem>
+ whenever superuser access is needed. The user should then
+ type <command>exit</command> to leave privileged access after
+ finishing the commands that required administrative access.
+ To add a user to this group, edit
+ <filename>/etc/group</filename> and add the user to the end of
+ the <literal>wheel</literal> entry. The user must be
separated by a comma character with no space.</para>
- <para>The second, and recommended, method to permit privilege escalation is
- to install the <package>security/sudo</package> package or port.
- This software provides additional auditing, more fine-grained user control,
- and can be configured to lock users into running only the specified privileged
+ <para>The second, and recommended, method to permit privilege
+ escalation is to install the <package>security/sudo</package>
+ package or port. This software provides additional auditing,
+ more fine-grained user control, and can be configured to lock
+ users into running only the specified privileged
commands.</para>
<para>After installation, use <command>visudo</command> to edit
- <filename>/usr/local/etc/sudoers</filename>.
- This example creates
- a new <systemitem class="groupname">webadmin</systemitem> group, adds the <systemitem
- class="username">trhodes</systemitem> account to that group, and
- configures that group access to restart
+ <filename>/usr/local/etc/sudoers</filename>. This example
+ creates a new <systemitem
+ class="groupname">webadmin</systemitem> group, adds the
+ <systemitem class="username">trhodes</systemitem> account to
+ that group, and configures that group access to restart
<package>apache24</package>:</para>
<screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput>
@@ -237,45 +239,42 @@
<sect2 xml:id="security-passwords">
<title>Password Hashes</title>
- <para>Passwords are a necessary evil of technology. When
- they must be used, they should be
- complex and a powerful hash mechanism should be used to
- encrypt the version that is stored in the password database. &os; supports the
+ <para>Passwords are a necessary evil of technology. When they
+ must be used, they should be complex and a powerful hash
+ mechanism should be used to encrypt the version that is stored
+ in the password database. &os; supports the
<acronym>DES</acronym>, <acronym>MD5</acronym>,
- <acronym>SHA256</acronym>, <acronym>SHA512</acronym>, and Blowfish hash algorithms in its
- <function>crypt()</function> library. The default of
- <acronym>SHA512</acronym> should not be changed to a less
- secure hashing algorithm, but can be changed to the more secure
- Blowfish algorithm.</para>
+ <acronym>SHA256</acronym>, <acronym>SHA512</acronym>, and
+ Blowfish hash algorithms in its <function>crypt()</function>
+ library. The default of <acronym>SHA512</acronym> should not
+ be changed to a less secure hashing algorithm, but can be
+ changed to the more secure Blowfish algorithm.</para>
<note>
- <para>Blowfish is not part of
- <acronym>AES</acronym> and is not considered compliant with
- any Federal Information
- Processing Standards (<acronym>FIPS</acronym>). Its use may not be
- permitted in some environments.</para>
+ <para>Blowfish is not part of <acronym>AES</acronym> and is
+ not considered compliant with any Federal Information
+ Processing Standards (<acronym>FIPS</acronym>). Its use may
+ not be permitted in some environments.</para>
</note>
<para>To determine which hash algorithm is used to encrypt a
user's password, the superuser can view the hash for the user
- in the &os; password database. Each hash
- starts with a symbol which indicates the type of hash
- mechanism used to encrypt the password. If
- <acronym>DES</acronym> is used, there is no beginning symbol.
- For
- <acronym>MD5</acronym>, the symbol is
+ in the &os; password database. Each hash starts with a symbol
+ which indicates the type of hash mechanism used to encrypt the
+ password. If <acronym>DES</acronym> is used, there is no
+ beginning symbol. For <acronym>MD5</acronym>, the symbol is
<literal>$</literal>. For <acronym>SHA256</acronym> and
- <acronym>SHA512</acronym>, the symbol is <literal>$6$</literal>.
- For Blowfish, the symbol is <literal>$2a$</literal>. In this
- example, the password for <systemitem
- class="username">dru</systemitem> is hashed using the default
- <acronym>SHA512</acronym> algorithm as the hash starts with
- <literal>$6$</literal>. Note that the encrypted hash, not the password
- itself, is stored in the password database:</para>
+ <acronym>SHA512</acronym>, the symbol is
+ <literal>$6$</literal>. For Blowfish, the symbol is
+ <literal>$2a$</literal>. In this example, the password for
+ <systemitem class="username">dru</systemitem> is hashed using
+ the default <acronym>SHA512</acronym> algorithm as the hash
+ starts with <literal>$6$</literal>. Note that the encrypted
+ hash, not the password itself, is stored in the password
+ database:</para>
<screen>&prompt.root; <userinput>grep dru /etc/master.passwd</userinput>
-dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh
-</screen>
+dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh</screen>
<para>The hash mechanism is set in the user's login class. For
this example, the user is in the <literal>default</literal>
@@ -286,83 +285,79 @@ dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3
<para>To change the algorithm to Blowfish, modify that line to
look like this:</para>
-
- <programlisting> :passwd_format=blf:\</programlisting>
-
- <para>Then run <command>cap_mkdb /etc/login.conf</command> as
+
+ <programlisting> :passwd_format=blf:\</programlisting>
+
+ <para>Then run <command>cap_mkdb /etc/login.conf</command> as
described in <xref linkend="users-limiting"/>. Note that this
change will not affect any existing password hashes. This
- means that all passwords should
- be re-hashed by asking users to run <command>passwd</command>
- in order to change their password.</para>
+ means that all passwords should be re-hashed by asking users
+ to run <command>passwd</command> in order to change their
+ password.</para>
- <para>For remote logins, two-factor
- authentication should be used. An example of two-factor authentication is
+ <para>For remote logins, two-factor authentication should be
+ used. An example of two-factor authentication is
<quote>something you have</quote>, such as a key, and
- <quote>something you know</quote>, such as the passphrase for that key. Since
- <application>OpenSSH</application> is part of the &os;
- base system, all network logins should be over an encrypted
- connection and use key-based authentication instead of passwords.
- For
- more information, refer to <xref linkend="openssh"/>.
- Kerberos users may need to make additional
- changes to implement <application>OpenSSH</application> in
- their network. These changes are described in <xref
- linkend="kerberos5"/>.</para>
- </sect2>
-
- <sect2 xml:id="security-pwpolicy">
- <title>Password Policy Enforcement</title>
-
- <para>Enforcing a strong password policy for local accounts
- is a fundamental aspect of system security.
- In &os;, password length,
- password strength, and password complexity
- can be implemented using built-in Pluggable Authentication
- Modules (<acronym>PAM</acronym>).</para>
-
- <para>This section demonstrates how to configure the minimum
- and maximum password length and the
- enforcement of mixed characters using the
- <filename>pam_passwdqc.so</filename> module. This module is enforced when
- a user changes their password.</para>
-
- <para>To configure this module, become the superuser and uncomment the line containing
- <literal>pam_passwdqc.so</literal> in
- <filename>/etc/pam.d/passwd</filename>. Then, edit that
- line to match the password policy:</para>
-
- <programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting>
-
- <para>This example
- sets several requirements for new passwords. The <literal>min</literal>
- setting controls the minimum
- password length. It has five values because this module
- defines five different types of passwords based on their
- complexity. Complexity is defined by the type of characters
- that must exist in a password, such as letters, numbers,
- symbols, and case. The types of passwords are described in
- &man.pam.passwdqc.8;. In this example, the first three
- types of passwords are disabled, meaning that passwords that
- meet those complexity requirements will not be accepted,
- regardless of their length.
- The <literal>12</literal> sets a minimum password policy of
- at least twelve characters, if the password also contains
- characters with three types of complexity. The
- <literal>10</literal> sets the password policy to also allow
- passwords of at least ten characters, if the password
- contains characters with four types of complexity.</para>
-
- <para>The <literal>similar</literal> setting denies passwords that
- are similar to the user's previous password. The
- <literal>retry</literal> setting provides a user with
- three opportunities to enter a new password.</para>
-
- <para>Once this file is saved, a user
- changing their password will see a message similar to the
- following:</para>
+ <quote>something you know</quote>, such as the passphrase for
+ that key. Since <application>OpenSSH</application> is part of
+ the &os; base system, all network logins should be over an
+ encrypted connection and use key-based authentication instead
+ of passwords. For more information, refer to <xref
+ linkend="openssh"/>. Kerberos users may need to make
+ additional changes to implement
+ <application>OpenSSH</application> in their network. These
+ changes are described in <xref linkend="kerberos5"/>.</para>
+ </sect2>
+
+ <sect2 xml:id="security-pwpolicy">
+ <title>Password Policy Enforcement</title>
+
+ <para>Enforcing a strong password policy for local accounts is a
+ fundamental aspect of system security. In &os;, password
+ length, password strength, and password complexity can be
+ implemented using built-in Pluggable Authentication Modules
+ (<acronym>PAM</acronym>).</para>
+
+ <para>This section demonstrates how to configure the minimum and
+ maximum password length and the enforcement of mixed
+ characters using the <filename>pam_passwdqc.so</filename>
+ module. This module is enforced when a user changes their
+ password.</para>
- <screen>&prompt.user; <userinput>passwd</userinput>
+ <para>To configure this module, become the superuser and
+ uncomment the line containing
+ <literal>pam_passwdqc.so</literal> in
+ <filename>/etc/pam.d/passwd</filename>. Then, edit that line
+ to match the password policy:</para>
+
+ <programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting>
+
+ <para>This example sets several requirements for new passwords.
+ The <literal>min</literal> setting controls the minimum
+ password length. It has five values because this module
+ defines five different types of passwords based on their
+ complexity. Complexity is defined by the type of characters
+ that must exist in a password, such as letters, numbers,
+ symbols, and case. The types of passwords are described in
+ &man.pam.passwdqc.8;. In this example, the first three types
+ of passwords are disabled, meaning that passwords that meet
+ those complexity requirements will not be accepted, regardless
+ of their length. The <literal>12</literal> sets a minimum
+ password policy of at least twelve characters, if the password
+ also contains characters with three types of complexity. The
+ <literal>10</literal> sets the password policy to also allow
+ passwords of at least ten characters, if the password contains
+ characters with four types of complexity.</para>
+
+ <para>The <literal>similar</literal> setting denies passwords
+ that are similar to the user's previous password. The
+ <literal>retry</literal> setting provides a user with three
+ opportunities to enter a new password.</para>
+
+ <para>Once this file is saved, a user changing their password
+ will see a message similar to the following:</para>
+
+ <screen>&prompt.user; <userinput>passwd</userinput>
Changing local password for trhodes
Old Password:
@@ -377,32 +372,34 @@ Alternatively, if noone else can see you
pick this as your password: "trait-useful&knob".
Enter new password:</screen>
- <para>If a password that does not match the policy is entered, it will be rejected with
- a warning and the user will have an opportunity to try
- again, up to the configured number of retries.</para>
-
- <para>Most password policies require passwords to
- expire after so many days. To set a
- password age time in &os;, set
- <option>passwordtime</option> for the user's login class in
- <filename>/etc/login.conf</filename>. The
- <literal>default</literal> login class contains an example:</para>
-
- <programlisting># :passwordtime=90d:\</programlisting>
-
- <para>So, to set an expiry of 90 days for this login class,
- remove the comment symbol (<literal>#</literal>), save the
- edit, and run <command>cap_mkdb /etc/login.conf</command>.</para>
-
- <para>To set the expiration on individual users, pass an
- expiration date or the number of days to expiry
- and a username to <command>pw</command>:</para>
-
- <screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen>
-
- <para>As seen here, an expiration date is set in the form of
- day, month, and year. For more information, see
- &man.pw.8;.</para>
+ <para>If a password that does not match the policy is entered,
+ it will be rejected with a warning and the user will have an
+ opportunity to try again, up to the configured number of
+ retries.</para>
+
+ <para>Most password policies require passwords to expire after
+ so many days. To set a password age time in &os;, set
+ <option>passwordtime</option> for the user's login class in
+ <filename>/etc/login.conf</filename>. The
+ <literal>default</literal> login class contains an
+ example:</para>
+
+ <programlisting># :passwordtime=90d:\</programlisting>
+
+ <para>So, to set an expiry of 90 days for this login class,
+ remove the comment symbol (<literal>#</literal>), save the
+ edit, and run <command>cap_mkdb
+ /etc/login.conf</command>.</para>
+
+ <para>To set the expiration on individual users, pass an
+ expiration date or the number of days to expiry and a username
+ to <command>pw</command>:</para>
+
+ <screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen>
+
+ <para>As seen here, an expiration date is set in the form of
+ day, month, and year. For more information, see
+ &man.pw.8;.</para>
</sect2>
<sect2 xml:id="security-rkhunter">
@@ -2053,18 +2050,18 @@ Connection closed by foreign host.</scre
<itemizedlist>
<listitem>
<para><emphasis>Encapsulated Security Payload
- (<acronym>ESP</acronym>)</emphasis>: this protocol protects
- the <acronym>IP</acronym> packet data from third party
- interference by encrypting the contents using symmetric
- cryptography algorithms such as Blowfish and
+ (<acronym>ESP</acronym>)</emphasis>: this protocol
+ protects the <acronym>IP</acronym> packet data from third
+ party interference by encrypting the contents using
+ symmetric cryptography algorithms such as Blowfish and
<acronym>3DES</acronym>.</para>
</listitem>
<listitem>
<para><emphasis>Authentication Header
- (<acronym>AH</acronym>)</emphasis>): this protocol protects
- the <acronym>IP</acronym> packet header from third party
- interference and spoofing by computing a cryptographic
+ (<acronym>AH</acronym>)</emphasis>): this protocol
+ protects the <acronym>IP</acronym> packet header from third
+ party interference and spoofing by computing a cryptographic
checksum and hashing the <acronym>IP </acronym> packet
header fields with a secure hashing function. This is then
followed by an additional header that contains the hash, to
@@ -2074,9 +2071,9 @@ Connection closed by foreign host.</scre
<listitem>
<para><emphasis>IP Payload Compression Protocol
- (<acronym>IPComp</acronym></emphasis>): this protocol tries
- to increase communication performance by compressing the
- <acronym>IP </acronym> payload in order ro reduce the
+ (<acronym>IPComp</acronym></emphasis>): this protocol
+ tries to increase communication performance by compressing
+ the <acronym>IP </acronym> payload in order ro reduce the
amount of data sent.</para>
</listitem>
</itemizedlist>
@@ -3532,9 +3529,8 @@ UWWemqWuz3lAZuORQ9KX
<para>&os; provides several methods for an administrator to
limit the amount of system resources an individual may use.
- Disk quotas limit the amount of disk space available to
- users. Quotas are discussed in
- <xref linkend="quotas"/>.</para>
+ Disk quotas limit the amount of disk space available to users.
+ Quotas are discussed in <xref linkend="quotas"/>.</para>
<indexterm>
<primary>quotas</primary>
@@ -3548,21 +3544,21 @@ UWWemqWuz3lAZuORQ9KX
</indexterm>
<para>Limits to other resources, such as <acronym>CPU</acronym>
- and memory, can be set using either a flat
- file or a command to configure a resource limits database. The
- traditional method defines login classes by editing
- <filename>/etc/login.conf</filename>. While this method
- is still supported, any changes require a multi-step process of
- editing this file, rebuilding the resource database, making necessary changes to
- <filename>/etc/master.passwd</filename>, and rebuilding the
- password database. This
- can become time consuming, depending upon the number of users to
+ and memory, can be set using either a flat file or a command to
+ configure a resource limits database. The traditional method
+ defines login classes by editing
+ <filename>/etc/login.conf</filename>. While this method is
+ still supported, any changes require a multi-step process of
+ editing this file, rebuilding the resource database, making
+ necessary changes to <filename>/etc/master.passwd</filename>,
+ and rebuilding the password database. This can become time
+ consuming, depending upon the number of users to
configure.</para>
<para>Beginning with &os; 9.0-RELEASE,
<command>rctl</command> can be used to provide a more
- fine-grained method for controlling resource limits.
- This command supports more than user limits as it can also be used to
+ fine-grained method for controlling resource limits. This
+ command supports more than user limits as it can also be used to
set resource constraints on processes and jails.</para>
<para>This section demonstrates both methods for controlling
@@ -3584,10 +3580,11 @@ UWWemqWuz3lAZuORQ9KX
<para>In the traditional method, login classes and the resource
limits to apply to a login class are defined in
- <filename>/etc/login.conf</filename>. Each user account can be assigned
- to a login class, where <literal>default</literal> is the default
- login class. Each login class has a set of login capabilities associated
- with it. A login capability is a
+ <filename>/etc/login.conf</filename>. Each user account can
+ be assigned to a login class, where <literal>default</literal>
+ is the default login class. Each login class has a set of
+ login capabilities associated with it. A login capability is
+ a
<literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>
pair, where <replaceable>name</replaceable> is a well-known
identifier and <replaceable>value</replaceable> is an
@@ -3595,63 +3592,63 @@ UWWemqWuz3lAZuORQ9KX
the <replaceable>name</replaceable>.</para>
<note>
- <para>Whenever
- <filename>/etc/login.conf</filename> is edited, the
- <filename>/etc/login.conf.db</filename> must be updated by
- executing the following command:</para>
+ <para>Whenever <filename>/etc/login.conf</filename> is edited,
+ the <filename>/etc/login.conf.db</filename> must be updated
+ by executing the following command:</para>
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
</note>
<para>Resource limits differ from the default login capabilities
- in two ways. First, for every limit, there is a <firstterm>soft</firstterm>
- and <firstterm>hard</firstterm> limit. A soft limit may be adjusted by the
- user or application, but may not be set higher than the hard
- limit. The hard limit may be lowered by the user, but can
- only be raised by the superuser. Second, most resource limits
- apply per process to a specific user.</para>
+ in two ways. First, for every limit, there is a
+ <firstterm>soft</firstterm> and <firstterm>hard</firstterm>
+ limit. A soft limit may be adjusted by the user or
+ application, but may not be set higher than the hard limit.
+ The hard limit may be lowered by the user, but can only be
+ raised by the superuser. Second, most resource limits apply
+ per process to a specific user.</para>
<para><xref linkend="resource-limits"/> lists the most commonly
- used resource limits. All of the available
- resource limits and capabilities are described in
- detail in &man.login.conf.5;.</para>
-
- <indexterm>
- <primary>limiting users</primary>
- <secondary>coredumpsize</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>cputime</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>filesize</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>maxproc</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>memorylocked</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>memoryuse</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>openfiles</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>sbsize</secondary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>stacksize</secondary>
- </indexterm>
+ used resource limits. All of the available resource limits
+ and capabilities are described in detail in
+ &man.login.conf.5;.</para>
+
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>coredumpsize</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>cputime</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>filesize</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>maxproc</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>memorylocked</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>memoryuse</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>openfiles</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>sbsize</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>stacksize</secondary>
+ </indexterm>
<table xml:id="resource-limits" frame="none" pgwide="1">
<title>Login Class Resource Limits</title>
@@ -3666,93 +3663,94 @@ UWWemqWuz3lAZuORQ9KX
<tbody>
<row>
- <entry>coredumpsize</entry>
- <entry>The limit on the size of a core file
- generated by a program is subordinate to other limits
- on disk usage, such as <literal>filesize</literal> or
- disk quotas. This limit is often used as a less severe
- method of controlling disk space consumption. Since
- users do not generate core files and often
- do not delete them, this setting may save them from
- running out of disk space should a large program
- crash.</entry>
- </row>
-
- <row>
- <entry>cputime</entry>
- <entry>The maximum amount of <acronym>CPU</acronym>
- time a user's process may consume. Offending processes
- will be killed by the kernel. This is a limit on
- <acronym>CPU</acronym> <emphasis>time</emphasis>
- consumed, not the percentage of the <acronym>CPU</acronym> as displayed in
- some of the fields generated by <command>top</command>
- and <command>ps</command>.</entry>
+ <entry>coredumpsize</entry>
+ <entry>The limit on the size of a core file generated by
+ a program is subordinate to other limits on disk
+ usage, such as <literal>filesize</literal> or disk
+ quotas. This limit is often used as a less severe
+ method of controlling disk space consumption. Since
+ users do not generate core files and often do not
+ delete them, this setting may save them from running
+ out of disk space should a large program
+ crash.</entry>
+ </row>
+
+ <row>
+ <entry>cputime</entry>
+ <entry>The maximum amount of <acronym>CPU</acronym> time
+ a user's process may consume. Offending processes
+ will be killed by the kernel. This is a limit on
+ <acronym>CPU</acronym> <emphasis>time</emphasis>
+ consumed, not the percentage of the
+ <acronym>CPU</acronym> as displayed in some of the
+ fields generated by <command>top</command> and
+ <command>ps</command>.</entry>
+ </row>
+
+ <row>
+ <entry>filesize</entry>
+ <entry>The maximum size of a file the user may own.
+ Unlike disk quotas (<xref linkend="quotas"/>), this
+ limit is enforced on individual files, not the set of
+ all files a user owns.</entry>
+ </row>
+
+ <row>
+ <entry>maxproc</entry>
+ <entry>The maximum number of foreground and background
+ processes a user can run. This limit may not be
+ larger than the system limit specified by
+ <varname>kern.maxproc</varname>. Setting this limit
+ too small may hinder a user's productivity as some
+ tasks, such as compiling a large program, start lots
+ of processes.</entry>
</row>
- <row>
- <entry>filesize</entry>
- <entry>The maximum size of a file
- the user may own. Unlike disk quotas
- (<xref linkend="quotas"/>), this limit is
- enforced on individual files, not the set of all files a
- user owns.</entry>
- </row>
-
- <row>
- <entry>maxproc</entry>
- <entry>The maximum number of foreground and background processes
- a user can run. This limit may not be larger than the system
- limit specified by <varname>kern.maxproc</varname>.
- Setting this limit too small may hinder
- a user's productivity as some tasks,
- such as compiling a large program, start lots of
- processes.</entry>
- </row>
-
- <row>
- <entry>memorylocked</entry>
- <entry>The maximum amount of memory
- a process may request to be locked into main memory
- using &man.mlock.2;. Some system-critical programs,
- such as &man.amd.8;, lock into main memory so that if
- the system begins to swap, they do not contribute to
- disk thrashing.</entry>
- </row>
-
- <row>
- <entry>memoryuse</entry>
- <entry>The maximum amount of memory
- a process may consume at any given time. It includes
- both core memory and swap usage. This is not a
- catch-all limit for restricting memory consumption, but
- is a good start.</entry>
- </row>
-
- <row>
- <entry>openfiles</entry>
- <entry>The maximum number of files a process may have open.
- In &os;, files are used to represent sockets and <acronym>IPC</acronym>
- channels, so be careful not to set this too low. The
- system-wide limit for this is defined by
- <varname>kern.maxfiles</varname>.</entry>
- </row>
-
- <row>
- <entry>sbsize</entry>
- <entry>The limit on the amount of network memory
- a user may consume. This can be generally used to limit
- network communications.</entry>
- </row>
-
- <row>
- <entry>stacksize</entry>
- <entry>The maximum size of a process stack.
- This alone is not sufficient to limit the amount of
- memory a program may use, so it should be used in
- conjunction with other limits.</entry>
- </row>
- </tbody>
- </tgroup>
+ <row>
+ <entry>memorylocked</entry>
+ <entry>The maximum amount of memory a process may
+ request to be locked into main memory using
+ &man.mlock.2;. Some system-critical programs, such as
+ &man.amd.8;, lock into main memory so that if the
+ system begins to swap, they do not contribute to disk
+ thrashing.</entry>
+ </row>
+
+ <row>
+ <entry>memoryuse</entry>
+ <entry>The maximum amount of memory a process may
+ consume at any given time. It includes both core
+ memory and swap usage. This is not a catch-all limit
+ for restricting memory consumption, but is a good
+ start.</entry>
+ </row>
+
+ <row>
+ <entry>openfiles</entry>
+ <entry>The maximum number of files a process may have
+ open. In &os;, files are used to represent sockets
+ and <acronym>IPC</acronym> channels, so be careful not
+ to set this too low. The system-wide limit for this
+ is defined by
+ <varname>kern.maxfiles</varname>.</entry>
+ </row>
+
+ <row>
+ <entry>sbsize</entry>
+ <entry>The limit on the amount of network memory a user
+ may consume. This can be generally used to limit
+ network communications.</entry>
+ </row>
+
+ <row>
+ <entry>stacksize</entry>
+ <entry>The maximum size of a process stack. This alone
+ is not sufficient to limit the amount of memory a
+ program may use, so it should be used in conjunction
+ with other limits.</entry>
+ </row>
+ </tbody>
+ </tgroup>
</table>
<para>There are a few other things to remember when setting
@@ -3766,29 +3764,29 @@ UWWemqWuz3lAZuORQ9KX
</listitem>
<listitem>
- <para>Although the default <filename>/etc/login.conf</filename>
- is a good source of reasonable
- values for most limits, they may not be appropriate for
- every system. Setting a limit too high may open the
- system up to abuse, while setting it too low may put a
- strain on productivity.</para>
+ <para>Although the default
+ <filename>/etc/login.conf</filename> is a good source of
+ reasonable values for most limits, they may not be
+ appropriate for every system. Setting a limit too high
+ may open the system up to abuse, while setting it too low
+ may put a strain on productivity.</para>
</listitem>
<listitem>
<para><application>&xorg;</application> takes a lot of
- resources and encourages users to run more
- programs simultaneously.</para>
+ resources and encourages users to run more programs
+ simultaneously.</para>
</listitem>
<listitem>
<para>Many limits apply to individual processes, not the
user as a whole. For example, setting
- <varname>openfiles</varname> to <literal>50</literal> means that each process
- the user runs may open up to <literal>50</literal> files. The total amount
- of files a user may open is the value of
- <literal>openfiles</literal> multiplied by the value of
- <literal>maxproc</literal>. This also applies to memory
- consumption.</para>
+ <varname>openfiles</varname> to <literal>50</literal>
+ means that each process the user runs may open up to
+ <literal>50</literal> files. The total amount of files a
+ user may open is the value of <literal>openfiles</literal>
+ multiplied by the value of <literal>maxproc</literal>.
+ This also applies to memory consumption.</para>
</listitem>
</itemizedlist>
More information about the svn-doc-head
mailing list